Aplicativos Reactive em OutSystems

Ciclo de vida de um Screen 

Nas OutSystems Mobile e Reactive Web Apps, os Ecrãs e Blocos seguem um ciclo de vida composto por um conjunto de fases. Algumas dessas etapas são quando você abre o aplicativo e entra na tela padrão, navega para outra tela ou altera os dados da tela ou do bloco. 

Os dados de uma tela ou bloco são os seguintes: 

• Parâmetros de entrada 
• Variáveis 
• Agregados e Ações de Dados 
• mensagens de validação 

Ao implementar um aplicativo da Web móvel ou reativo, o desenvolvedor pode atuar nesses estágios usando um conjunto de ações do manipulador de eventos. Esses manipuladores de eventos fornecem ao desenvolvedor visibilidade sobre a tela e o ciclo de vida do bloco e a oportunidade de implementar a lógica quando ocorrem determinados eventos. 

Você pode ver e definir os manipuladores de eventos na seção Eventos do editor de propriedades de Telas e Blocos, ou para o manipulador de eventos acionado quando os dados terminam de ser buscados, no editor de propriedades de Agregados ou Ações de Dados. 

Estágios do ciclo de vida 

Ao abrir o aplicativo 

A abertura de um aplicativo é uma das situações em que uma tela é carregada (a outra situação é a navegação a partir de outra tela). Nesse caso, o aplicativo exibe a tela inicial configurada e navega para a tela padrão. 

Ao exibir a tela inicial, o aplicativo verifica a função do usuário em relação às funções com permissão para acessar a tela (definidas nas propriedades da tela). Após esta verificação, o evento Initialize acontece e a respectiva ação do manipulador de eventos, o On Initialize é acionado. Como o DOM da tela padrão não é totalmente carregado quando esse evento ocorre, você pode usar esse manipulador de eventos para implementar toda a lógica que não requer o DOM, como inicializar alguns dados padrão. 

Quando o manipulador de eventos On Initialize termina, os Agregados e as Ações de dados da tela padrão começam simultaneamente a buscar dados (exemplificado pelos GetContacts e GetProfileImages da imagem acima), o DOM da tela é carregado e os manipuladores de eventos Ready e Render são executados . A diferença entre esses dois eventos é que o evento Ready só acontece ao abrir a tela enquanto o evento Render também acontece toda vez que os dados da tela (como parâmetros de entrada, variáveis, agregados e ações de dados ou mensagens de validação) são modificados. Você pode usar ambos os manipuladores de eventos para agir no DOM carregado. Evite acessar os dados da tela, pois esses dados ainda não podem ser buscados. 

Antes mesmo de buscar os dados dos agregados e das ações de dados, a tela aparece para o usuário com os recursos estáticos. Para evitar essa situação, adote uma primeira abordagem de implementação off-line. 

Quando os agregados e as ações de dados da tela terminam de buscar os dados, os widgets vinculados a essas fontes de dados são atualizados automaticamente com os dados buscados. O manipulador de eventos After Fetch de cada ação agregada e de dados é executado, seguido pelo evento Render (já que os dados da tela foram modificados). Para cada evento After Fetch, o aplicativo executa um evento Render. 

Sobre a navegação entre as telas 

Navegar de uma tela para outra é um padrão muito comum de aplicativos. Isso geralmente é acionado por uma interação do usuário, como clicar em um botão ou item de lista na tela. A navegação entre ecrãs no OutSystems significa que é carregado um novo ecrã e depois removido o ecrã anterior. 

Quando a navegação começa, o DOM da tela de destino começa a carregar imediatamente. Isso significa que o DOM da tela a ser removida e a tela de destino estão presentes ao mesmo tempo. O DOM da tela antiga é removido somente após o evento Render da tela de destino, garantindo uma transição rápida e suave entre as telas e evitando a exibição dos estágios de carregamento da tela de destino para o usuário. 

O primeiro manipulador de eventos a ser executado é o On Initialize . O aplicativo continua carregando o DOM da tela de destino seguido de seus eventos, conforme documentado na seção de abertura do aplicativo. Como esses eventos pertencem à tela de destino, a tela ativa é a tela de destino e a active-screenclasse no DOM é atribuída aos elementos dessa tela. 

Após o evento Render da tela de destino, ocorre a transição entre as telas e a tela mais antiga é finalmente removida do DOM. Isso significa que o DOM de ambas as telas estão disponíveis entre o evento Render da tela de destino e o evento Destroy da tela antiga. 

Sobre a alteração dos dados de uma tela ou bloco 

Toda vez que você altera o valor de um elemento de dados de uma Tela ou Bloco, o aplicativo automaticamente reage a isso. Assim, o evento Render é acionado e os elementos da interface do usuário que dependem dos dados são atualizados automaticamente. Você não precisa atualizar explicitamente os elementos da interface do usuário como precisa fazer para aplicativos da web. 

Para agregações de tela ou bloco e ações de dados, seus novos valores são atualizados automaticamente nos elementos da interface do usuário, mas você precisa executar novamente a consulta explicitamente. Isso pode ser feito usando o elemento de fluxo Atualizar dados na lógica. 

Após a busca dos dados, ocorre o evento After Fetch e, como os dados retornados do Aggregate ou Data Action pertencem à tela ou dados do bloco e foram alterados, também ocorre o evento Render. 

Como exemplo, imagine uma tela mostrando os detalhes de um contato junto com a lista de chamadas para esse contato. Para obter as chamadas, você usa um Agregado filtrado pelo valor da variável da tela atribuída ao identificador do contato atual. Quando o contato mudar, a tela exibirá os detalhes do novo contato, portanto, a variável da tela é modificada para conter o novo identificador do contato. Para obter a lista de chamadas para este novo contato, o Agregado deve ser executado novamente. Para isso, basta chamar o elemento Refresh Data flow na lógica e selecionar o respectivo Aggregate ou Data Action. Quando a consulta retornar a nova lista de chamadas, a lista na tela é atualizada automaticamente. 

Ao alterar os parâmetros de um bloco 

Para permitir a notificação e atualização de um bloco quando um de seus parâmetros de entrada é alterado, o aplicativo executa o manipulador de eventos Parameters Changed do bloco. Um caso de uso comum para este manipulador de eventos é executar novamente algum Aggregate ou Data Action que dependa do parâmetro de entrada, conforme exemplificado na imagem acima onde após uma alteração na data do calendário, a consulta é executada novamente para obter novos valores para o gráfico . 

Como o parâmetro de entrada faz parte dos dados do Bloco, o evento Render também é acionado, mas somente após o evento Alteração de Parâmetros. 

Versão texto: 

On Initialize: Ocorre após a verificação da permissão do usuário para acessar a Tela, mas antes de navegar até a Tela e buscar os dados. Nos Blocos, ocorre após a navegação. Você pode usá-lo para inicializar a Tela ou o Bloco definindo seus dados padrão. 

On Ready: Ocorre após o DOM de Tela ou Bloco estar pronto, antes do início da transição. 

On Render: Ocorre logo após o manipulador de Aplicativos Reactive em Outsystems 11 eventos Screen ou Block On Ready e sempre que os dados de uma Tela ou Bloco são alterados. Você pode usá-lo para atualizar algum componente de terceiros. 

On After Fetch: Ocorre depois que um Agregado ou Ação de Dados termina de buscar dados, mas antes que esses dados sejam renderizados na Tela ou Bloco. Você pode usá-lo para agir sobre os dados recuperados. 

On Parameters Changed: Ocorre em um Bloco sempre que a Tela ou Bloco pai altera um de seus parâmetros de entrada. Alterações no valor de entrada dentro do bloco não acionam esse manipulador de eventos. Você pode usá-lo para reagir a mudanças nos parâmetros do Bloco, como para atualizar variáveis. 

On Destroy: Ocorre antes de destruir uma Tela ou Bloco e removê-lo do DOM. Você pode usá-lo para implementar a lógica quando o componente for descartado, como para remover ouvintes de eventos. 

On Initialize 

O manipulador de eventos On Initialize é executado após verificar a permissão do usuário para acessar a Tela, mas antes de navegar até a Tela e iniciar a busca de dados. 

Nos Blocos, incluir qualquer chamada de ação do servidor ou operações de 

armazenamento local nesse fluxo pode fazer com que a renderização do Bloco seja iniciada antes que essa ação seja concluída. Você terá problemas se definir quaisquer variáveis nesse fluxo que afetem a renderização. 

Notas: 

• Mantenha essa ação do manipulador de eventos simples e evite ações lentas, 

como operações de armazenamento local, pois isso pode atrasar a renderização da Tela ou do Bloco. 

• Evite acessar os dados da Tela ou do Bloco, pois esta ação é executada antes 

que os dados sejam buscados. 

• Casos de uso que você pode implementar com este manipulador de eventos: 
• Atribua uma variável com base nas entradas. 
• Atribua uma variável com base em alguma computação em JavaScript, como um número aleatório. 
• Redirecionar a aplicação para outra Tela se o usuário não tiver autorização para ver a Tela (possível somente se o manipulador de eventos pertencer a uma Tela). 
• Atribua os parâmetros de um Bloco filho com base nas entradas da Tela. 
• Variáveis de acesso do objeto de janela JavaScript. 

On Ready 

O manipulador de eventos On Ready é executado quando a Tela ou Bloco está pronto, ou seja, quando o DOM está pronto, após a primeira renderização. Nos Blocos, este evento acontece antes do mesmo evento da Tela ou Bloco pai. Para garantir uma renderização de tela ou bloco rápida e suave, esse evento é acionado antes mesmo da transição para a tela terminar. 

Notas: 

O DOM das Telas anterior e atual são carregados quando este evento é 

acionado. Para garantir que você está operando na tela que está sendo criada, execute a lógica apenas para o div elemento HTML com a classe activescreen. Mantenha essa ação do manipulador de eventos simples e evite usar Agregados de Tela ou Ações de Dados, que são executados em paralelo, para manipular dados que podem não estar disponíveis.Evite acessar os dados da Tela ou do Bloco, pois esta ação é executada antes que os dados sejam buscados. Se você precisar desenvolver alguma lógica nesses dados, use o manipulador de eventos On After Fetch do respectivo Aggregate ou Data Action. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Inicialize um componente de terceiros que precise do DOM. 
• Adicione ouvintes a um elemento DOM. 
• Defina o foco em um widget de entrada. 
• Adicione ouvintes ao objeto de janela JavaScript. 

On Render 

O manipulador de eventos On Render é executado após cada renderização da Tela ou Bloco, ou seja, sempre que a Tela ou Bloco é aberto (logo após a execução do manipulador de eventos On Ready) e após qualquer alteração dos dados da Tela. Nos Blocos, este evento acontece antes do mesmo evento da Tela ou Bloco pai. Você pode usar esse manipulador de eventos para atualizar um componente de terceiros, como uma barra de progresso. 

Notas: 

Evite alterar os dados de tela ou bloco, pois toda vez que esses dados são 

alterados, o evento On Render é acionado novamente e o aplicativo pode ser 

executado em um loop infinito. 

Mantenha essa ação de manipulador de eventos simples e evite ações lentas, como solicitações do servidor, pois isso pode atrasar a renderização da Tela ou do Bloco. Na primeira renderização da Tela ou Bloco evite acessar os dados da Tela ou Bloco, pois não há garantia de que os dados já foram buscados. Se você precisar desenvolver alguma lógica nesses dados, use o manipulador de eventos On After Fetch do respectivo Aggregate ou Data Action. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Atuar em uma alteração nos dados da Tela ou Bloco para atualizar um componente de terceiros. Os mesmos casos de uso do manipulador de eventos On Ready. 

On After Fetch 

O manipulador de eventos On After Fetch é executado logo após um Aggregate ou Data Action terminar de buscar dados. Como cada Agregação ou Ação de Dados tem seu próprio manipulador de eventos On After Fetch, você pode implementar a lógica para agir sobre os dados recuperados dessa fonte de dados. 

Notas: 

Quando o manipulador de eventos On After Fetch é executado, os dados chegam e estão disponíveis, mas não estão vinculados a widgets. Isso significa que os widgets ainda não foram atualizados. Casos de uso que você pode implementar com este manipulador de eventos: 

Atribua o primeiro ou último registro retornado pela consulta a uma variável. No padrão mestre-detalhe, para iterar uma consulta para preencher uma lista de listas. Para consultas dependentes de outras consultas, você pode usar esse manipulador de eventos para acionar o Agregado dependente.  

Casos de uso que você não deve implementar com este manipulador de eventos: 

• Não use a função GetUserId() neste momento para conhecer o usuário que está autenticado no momento. A execução paralela de Ações de Dados e Agregados do lado do cliente em uma Tela substitui o cookie de autenticação de sessão. Portanto, usar a função GetUserId() no evento On After Fetch pode retornar um valor vazio. 

On Parameters Changed 

O On Parameters Changed é um manipulador de eventos apenas para Blocos que são executados após a Tela ou Bloco pai alterar uma entrada do Bloco. Caso você tenha um Bloco dentro de outro Bloco e uma alteração de uma entrada do Bloco externo afete uma entrada do Bloco aninhado, o manipulador de eventos On Parameters Changed do Bloco externo é executado antes do mesmo evento do Bloco aninhado. Você pode usar este manipulador de eventos para adaptar o Bloco às alterações de parâmetros de entrada, como atualizar variáveis ou executar novamente Agregados e Ações de Dados. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Atualize um Agregado ou Ação de Dados que dependa desse parâmetro de entrada. 
• Recalcular uma variável que depende do parâmetro de entrada. 

On Destroy 

O manipulador de eventos On Destroy é executado quando a Tela ou Bloco vai ser destruído. Nas Telas, este evento acontece quando termina a transição para a nova Tela. Em Blocks, este evento acontece antes que o Block seja removido do DOM. Este evento é acionado seguindo uma ordem de cima para baixo: caso você tenha uma Tela com Blocos aninhados, o evento acontece primeiro na Tela, depois no Bloco externo e depois nos Blocos aninhados. Você pode usar esse manipulador de eventos para implementar a lógica para remover qualquer pegada da Tela ou do Bloco, como remover ouvintes de eventos. 

Notas: 

O DOM das telas presente e de destino é carregado quando este evento é 

acionado. Para garantir que você está operando na tela que está sendo destruída, execute a lógica apenas para o div elemento HTML com a classe activescreen. Mantenha essa ação do event handler simples e evite ações lentas como requisições do servidor, pois isso pode atrasar a remoção da Tela ou Bloco e, no caso de sair de uma tela, o carregamento da próxima tela. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Chame a ação de destruição de componentes de terceiros. 
• Limpe o DOM para executar um plugin novamente. 
• Remova os ouvintes JavaScript. 

Timers 

Um Timer é uma ferramenta da OutSystems que permite executar a lógica da aplicação periodicamente em um horário programado. Eles também são conhecidos como trabalhos em lote. 

Você pode usar Timers para executar lógica assíncrona em seu aplicativo OutSystems. Isso é útil para executar tarefas em lote, como enviar e-mails em um horário predeterminado, ou para executar lógica para configurar um aplicativo após sua implantação. 

Diferentes Timers podem ser executados ao mesmo tempo, mas o mesmo Timer nunca tem mais de uma execução por vez. 

Seguem-se alguns cenários comuns onde pode utilizar temporizadores: 

Trabalhos agendados: Execute o mesmo trabalho todos os dias no mesmo horário. Por exemplo, envie todos os dias às 4 da manhã e-mails para assinantes com notícias resumidas. Crie um Timer para executar uma Ação que faça o trabalho de enviar e-mails aos assinantes todos os dias às 4 da manhã 

Executando ações de longa duração: Execute a lógica do aplicativo que geralmente leva muito tempo para terminar. Por exemplo, às 2h do primeiro dia de cada mês, o sistema deve arquivar muitos registos do banco de dados. Demora cerca de 2 horas. Crie um Timer para executar uma Ação que arquive registos e configure-o para ser executado às 2h do primeiro dia de cada mês e com o tempo limite padrão de 150 minutos (este valor pode ser ajustado na Central de Atendimento). 

Arquitetura 

A tabela a seguir lista os elementos OutSystems relacionados aos Timers: 

Serviço OutSystems Scheduler: Este é o serviço que tem a responsabilidade de verificar se os Timers serão executados. É um serviço multi-threaded que permite ter diferentes Timers executando ao mesmo tempo. 

Banco de dados de tempo de execução: O banco de dados de tempo de execução contém todas as entidades do Sistema para gerenciamento de Timers, como: 

- O registro de todos os Timers existentes. 

- A programação para a execução de temporizadores. 

- Execução atual dos Timers: quando iniciados, seu tempo limite ou próxima execução. 

Banco de Dados de Log: Quando um Timer é executado, uma entrada é criada no banco de dados Log. 

Ferramenta de configuração: Esta é a ferramenta que permite configurar o número máximo de Timers que podem ser executados ao mesmo tempo em cada nó do servidor front-end. 

OutSystems Logs: No Service Center, você pode acessar os logs do Timer para aplicativos individuais ou todos os aplicativos em seu ambiente. 

Módulo implantado (aplicativo): O aplicativo implantado contém o código para o Timer. Possui a lógica da aplicação desenhada na Action executada pelo Timer, e também algum código stub necessário para atualizar o banco de dados do sistema sobre o estado do Timer. 

Como os temporizadores são executados 

O Scheduler Service é responsável por executar todos os Timers. Este serviço é multi-threaded, portanto, permite executar diferentes Timers ao mesmo tempo. Para simplificar, as etapas abaixo descrevem a execução de um único Timer. 

Os passos para executar os Timers são os seguintes: 

1. O Scheduler Service busca ciclicamente o banco de dados para que os Timers sejam executados ( Next_Run ). 
2. O Scheduler Service lança uma thread para executar o Timer que chama um Web Service no módulo onde está definido o Timer para executá-lo. 
3. O Web Service verifica primeiro se o Timer já está em execução em algum nó do Servidor Front-end. Caso contrário, os atributos Is_Running_Since e Is_Running_By da entidade Cyclic_Job_Shared são atualizados. Isso bloqueia a execução do Timer em qualquer outro nó de servidor front-end. 
4. O módulo executa a ação associada ao Timer. 
5. Após o término da execução da ação, os atributos Is_Running_Since e Is_Running_By são limpos, o que libera o Timer para uma nova execução. O atributo Next_Run é recalculado com base no atributo Schedule e na data e hora atuais. 

Em relação ao atributo Next_Run , ele é atualizado somente se não foi alterado durante a execução da ação. Isso pode acontecer se, por exemplo, a própria ação atualizar esse atributo. 

1. Um registro com as informações sobre a execução do Timer é enviado para o Log Service que o armazena no Log Database. 
2. O Web Service devolve o controle para o Scheduler Service, que agora fica pronto para executar outro Timer (passo 1.). 

Por que um tempo limite em Timers? 

Conforme descrito anteriormente, o Scheduler Service executa um Timer chamando um Web Service construído no módulo onde o Timer foi criado. Isso significa que existe uma Web Request envolvida na execução dos Timers e, como em qualquer Web Request, há um tempo máximo permitido para que ela seja executada no servidor. É por isso que os Timers possuem a propriedade 'Timeout em Minutos' no Service Studio, que por padrão está configurado para 20 minutos, mas você pode ajustar a cada caso. 

Gerenciando temporizadores no centro de serviços 

O Service Center disponibiliza um conjunto de funcionalidades que lhe permitem gerir os seus Timers, nomeadamente: 

• Monitore a execução dos Timers 
• Edite as configurações do temporizador 
• Forçar a execução de um Timer 
• Desativar/Ativar um Timer 
• Navegue pelos logs de execuções anteriores 

Monitorando a execução de Timers 

No Service Center, você pode monitorar a execução de seus Timers na opção Environment Health, em Monitoramento. A página possui uma seção de Timers com uma lista que mostra a ordem pela qual os Timers são executados. 

Os critérios para classificar os temporizadores na lista são baseados no seguinte: 

• A prioridade do temporizador. 
• O tempo que um Timer leva para ser executado, com base em sua duração anterior. Os temporizadores com tempos de execução mais rápidos são executados primeiro. 
• O tempo que um Timer está esperando para ser executado. À medida que o tempo de espera do Timer cresce, ele tende a subir na lista. 

Criar o temporizador 

Para criar um Timer em seu módulo, faça o seguinte: 

1. Na árvore do módulo, na guia Processo, clique com o botão direito do mouse na pasta Timer e selecione Adicionar Timer. 
2. Escolha a ação a ser executada quando o cronômetro for executado ou selecione (Nova ação do servidor) para criar uma ação. 

Se a Action que você especificar tiver parâmetros de entrada, ao criar o Timer, você precisará especificar os valores que serão passados ​​como parâmetros quando o Timer for ativado. Porém, se a ação possuir parâmetros de saída, não há como acessá-los após o término da execução da ação. 

Você pode definir um agendamento para executar o Timer automaticamente ou pode forçar o Timer a ser executado sem esperar pelo horário agendado. 

Definir a programação do temporizador 

Você pode definir a programação de um Timer de uma das seguintes maneiras: 

• Configurando a Schedule propriedade do Timer em tempo de design: Você pode definir uma programação recorrente, como diária ou semanal, ou definir o Timer para ser executado sempre que o módulo for publicado, por exemplo, para executar configurações ou dados de bootstrap. 

• Configurando a programação do Timer em tempo de execução no Service Center: Nos casos em que você precisa personalizar a programação do Timer ao implantar um aplicativo em outro ambiente, não há necessidade de alterar o aplicativo. A programação efetiva do Timer é definida no Service Center, que usa as configurações padrão em todos os ambientes, a menos que seja especificamente modificado. 
• Implemente a lógica que altera a programação do Timer em tempo de execução: atribua a Schedule propriedade de tempo de execução do Timer com uma programação específica dentro de sua lógica. Certifique-se de usar o formato de hora correto. 

Quando você define uma programação para seu Timer, o Timer será executado no horário predefinido. 

Forçar o Timer a funcionar 

Existem duas formas de forçar um Timer a funcionar sem esperar pela hora programada: 

• Usando a Wake<Timer Name>ação integrada 
• Executando o Timer no Centro de Serviços 

Nenhuma dessas opções altera a programação do timer, portanto, o Timer continuará funcionando normalmente. Além disso, como o mesmo Timer não é executado duas vezes simultaneamente, se você executar um Timer que já esteja em execução, a segunda execução só será iniciada após o término da primeira. 

Use a ação integrada do WakeTimer 

Quando você cria um Timer, uma ação integrada é fornecida para permitir que você execute o timer de forma programática. Essa ação é chamada Wake<Timer Name> e pode ser usada na lógica do seu aplicativo. 

Quando a Wake<Timer Name> ação é executada, a NextRun propriedade desse Timer é atualizada para o tempo atual. O timer será então tratado pelo Scheduler Server e executado de acordo com suas prioridades. 

A Wake<Timer Name>ação não recebe nenhum parâmetro de entrada e não retorna nenhum parâmetro de saída. 

Para usar a Wake<Timer Name> ação integrada em sua lógica, faça o seguinte: 

1. Na guia Processo, expanda o elemento Temporizador. 
2. Arraste a Wake<Timer Name>ação e use-a em sua lógica. 

Execute um cronômetro no centro de serviço 

Para forçar a execução de um Timer na Central de Atendimento, faça o seguinte: 

1. Na guia Factory , escolha Modules e encontre seu módulo. 
2. Na página de detalhes do módulo, escolha a guia Timers. 
3. Clique no Timer que deseja executar. 
4. Clique no botão Executar agora. 

Editando um Temporizador 

Você pode editar um Timer clicando no nome do Timer em um dos seguintes locais na Central de Serviços: 

• Módulo: edite o módulo onde está definido o Timer, selecione a aba Timers, e uma lista de Timers é exibida. 
• Registo de temporizadores: vá para a página de registo de temporizadores onde cada linha da lista tem o nome do temporizador. 
• Integridade do ambiente: vá para a página Integridade do ambiente, verifique a seção Timers onde cada linha da lista tem o nome do Timer. 

Desativando/ativando um temporizador 

Para interromper a execução de um Timer (obtido pelo Serviço Agendador e consumir recursos), pressione o botão Desativar na parte inferior da página. O Timer não será mais buscado pelo Serviço Agendador. Isso não interromperá um cronômetro em execução, apenas interromperá outras execuções. 

Se o Timer estiver desativado, o botão mostra Ativar e você deve pressioná-lo para que o Timer volte a funcionar. e um Screen 

Nas OutSystems Mobile e Reactive Web Apps, os Ecrãs e Blocos seguem um ciclo de vida composto por um conjunto de fases. Algumas dessas etapas são quando você abre o aplicativo e entra na tela padrão, navega para outra tela ou altera os dados da tela ou do bloco. 

Os dados de uma tela ou bloco são os seguintes: 

• Parâmetros de entrada 
• Variáveis 
• Agregados e Ações de Dados 
• mensagens de validação 

Ao implementar um aplicativo da Web móvel ou reativo, o desenvolvedor pode atuar nesses estágios usando um conjunto de ações do manipulador de eventos. Esses manipuladores de eventos fornecem ao desenvolvedor visibilidade sobre a tela e o ciclo de vida do bloco e a oportunidade de implementar a lógica quando ocorrem determinados eventos. 

Você pode ver e definir os manipuladores de eventos na seção Eventos do editor de propriedades de Telas e Blocos, ou para o manipulador de eventos acionado quando os dados terminam de ser buscados, no editor de propriedades de Agregados ou Ações de Dados.

Estágios do ciclo de vida 

 Ao abrir o aplicativo 

A abertura de um aplicativo é uma das situações em que uma tela é carregada (a outra situação é a navegação a partir de outra tela). Nesse caso, o aplicativo exibe a tela inicial configurada e navega para a tela padrão. 

Ao exibir a tela inicial, o aplicativo verifica a função do usuário em relação às funções com permissão para acessar a tela (definidas nas propriedades da tela). Após esta verificação, o evento Initialize acontece e a respectiva ação do manipulador de eventos, o On Initialize é acionado. Como o DOM da tela padrão não é totalmente carregado quando esse evento ocorre, você pode usar esse manipulador de eventos para implementar toda a lógica que não requer o DOM, como inicializar alguns dados padrão. 

Quando o manipulador de eventos On Initialize termina, os Agregados e as Ações de dados da tela padrão começam simultaneamente a buscar dados (exemplificado pelos GetContacts e GetProfileImages da imagem acima), o DOM da tela é carregado e os manipuladores de eventos Ready e Render são executados . A diferença entre esses dois eventos é que o evento Ready só acontece ao abrir a tela enquanto o evento Render também acontece toda vez que os dados da tela (como parâmetros de entrada, variáveis, agregados e ações de dados ou mensagens de validação) são modificados. Você pode usar ambos os manipuladores de eventos para agir no DOM carregado. Evite acessar os dados da tela, pois esses dados ainda não podem ser buscados. 

Antes mesmo de buscar os dados dos agregados e das ações de dados, a tela aparece para o usuário com os recursos estáticos. Para evitar essa situação, adote uma primeira abordagem de implementação off-line. 

Quando os agregados e as ações de dados da tela terminam de buscar os dados, os widgets vinculados a essas fontes de dados são atualizados automaticamente com os dados buscados. O manipulador de eventos After Fetch de cada ação agregada e de dados é executado, seguido pelo evento Render (já que os dados da tela foram modificados). Para cada evento After Fetch, o aplicativo executa um evento Render. 

Sobre a navegação entre as telas 

Navegar de uma tela para outra é um padrão muito comum de aplicativos. Isso geralmente é acionado por uma interação do usuário, como clicar em um botão ou item de lista na tela. A navegação entre ecrãs no OutSystems significa que é carregado um novo ecrã e depois removido o ecrã anterior. 

Quando a navegação começa, o DOM da tela de destino começa a carregar imediatamente. Isso significa que o DOM da tela a ser removida e a tela de destino estão presentes ao mesmo tempo. O DOM da tela antiga é removido somente após o evento Render da tela de destino, garantindo uma transição rápida e suave entre as telas e evitando a exibição dos estágios de carregamento da tela de destino para o usuário. 

O primeiro manipulador de eventos a ser executado é o On Initialize . O aplicativo continua carregando o DOM da tela de destino seguido de seus eventos, conforme documentado na seção de abertura do aplicativo. Como esses eventos pertencem à tela de destino, a tela ativa é a tela de destino e a active-screenclasse no DOM é atribuída aos elementos dessa tela. 

Após o evento Render da tela de destino, ocorre a transição entre as telas e a tela mais antiga é finalmente removida do DOM. Isso significa que o DOM de ambas as telas estão disponíveis entre o evento Render da tela de destino e o evento Destroy da tela antiga. 

Sobre a alteração dos dados de uma tela ou bloco 

Toda vez que você altera o valor de um elemento de dados de uma Tela ou Bloco, o aplicativo automaticamente reage a isso. Assim, o evento Render é acionado e os elementos da interface do usuário que dependem dos dados são atualizados automaticamente. Você não precisa atualizar explicitamente os elementos da interface do usuário como precisa fazer para aplicativos da web. 

Para agregações de tela ou bloco e ações de dados, seus novos valores são atualizados automaticamente nos elementos da interface do usuário, mas você precisa executar novamente a consulta explicitamente. Isso pode ser feito usando o elemento de fluxo Atualizar dados na lógica. 

Após a busca dos dados, ocorre o evento After Fetch e, como os dados retornados do Aggregate ou Data Action pertencem à tela ou dados do bloco e foram alterados, também ocorre o evento Render. 

Como exemplo, imagine uma tela mostrando os detalhes de um contato junto com a lista de chamadas para esse contato. Para obter as chamadas, você usa um Agregado filtrado pelo valor da variável da tela atribuída ao identificador do contato atual. Quando o contato mudar, a tela exibirá os detalhes do novo contato, portanto, a variável da tela é modificada para conter o novo identificador do contato. Para obter a lista de chamadas para este novo contato, o Agregado deve ser executado novamente. Para isso, basta chamar o elemento Refresh Data flow na lógica e selecionar o respectivo Aggregate ou Data Action. Quando a consulta retornar a nova lista de chamadas, a lista na tela é atualizada automaticamente. 

Ao alterar os parâmetros de um bloco 

Para permitir a notificação e atualização de um bloco quando um de seus parâmetros de entrada é alterado, o aplicativo executa o manipulador de eventos Parameters Changed do bloco. Um caso de uso comum para este manipulador de eventos é executar novamente algum Aggregate ou Data Action que dependa do parâmetro de entrada, conforme exemplificado na imagem acima onde após uma alteração na data do calendário, a consulta é executada novamente para obter novos valores para o gráfico . 

Como o parâmetro de entrada faz parte dos dados do Bloco, o evento Render também é acionado, mas somente após o evento Alteração de Parâmetros. 

On Initialize: Ocorre após a verificação da permissão do usuário para acessar a Tela, mas antes de navegar até a Tela e buscar os dados. Nos Blocos, ocorre após a navegação. Você pode usá-lo para inicializar a Tela ou o Bloco definindo seus dados padrão. 

On Ready: Ocorre após o DOM de Tela ou Bloco estar pronto, antes do início da transição. 

On Render: Ocorre logo após o manipulador de Aplicativos Reactive em Outsystems 11 eventos Screen ou Block On Ready e sempre que os dados de uma Tela ou Bloco são alterados. Você pode usá-lo para atualizar algum componente de terceiros. 

On After Fetch: Ocorre depois que um Agregado ou Ação de Dados termina de buscar dados, mas antes que esses dados sejam renderizados na Tela ou Bloco. Você pode usá-lo para agir sobre os dados recuperados. 

On Parameters Changed: Ocorre em um Bloco sempre que a Tela ou Bloco pai altera um de seus parâmetros de entrada. Alterações no valor de entrada dentro do bloco não acionam esse manipulador de eventos. Você pode usá-lo para reagir a mudanças nos parâmetros do Bloco, como para atualizar variáveis. 

On Destroy: Ocorre antes de destruir uma Tela ou Bloco e removê-lo do DOM. Você pode usá-lo para implementar a lógica quando o componente for descartado, como para remover ouvintes de eventos. 

On Initialize 

O manipulador de eventos On Initialize é executado após verificar a permissão do 

usuário para acessar a Tela, mas antes de navegar até a Tela e iniciar a busca de 

dados. 

Nos Blocos, incluir qualquer chamada de ação do servidor ou operações de 

armazenamento local nesse fluxo pode fazer com que a renderização do Bloco seja 

iniciada antes que essa ação seja concluída. Você terá problemas se definir 

quaisquer variáveis nesse fluxo que afetem a renderização. 

Notas: 

• Mantenha essa ação do manipulador de eventos simples e evite ações lentas, 

como operações de armazenamento local, pois isso pode atrasar a renderização da Tela ou do Bloco. 

• Evite acessar os dados da Tela ou do Bloco, pois esta ação é executada antes 

que os dados sejam buscados. 

• Casos de uso que você pode implementar com este manipulador de eventos: 
• Atribua uma variável com base nas entradas. 
• Atribua uma variável com base em alguma computação em JavaScript, como um número aleatório. 
• Redirecionar a aplicação para outra Tela se o usuário não tiver autorização para ver a Tela (possível somente se o manipulador de eventos pertencer a uma Tela). 
• Atribua os parâmetros de um Bloco filho com base nas entradas da Tela. 
• Variáveis de acesso do objeto de janela JavaScript. 

On Ready 

O manipulador de eventos On Ready é executado quando a Tela ou Bloco está pronto, ou seja, quando o DOM está pronto, após a primeira renderização. Nos Blocos, este evento acontece antes do mesmo evento da Tela ou Bloco pai. Para garantir uma renderização de tela ou bloco rápida e suave, esse evento é acionado antes mesmo da transição para a tela terminar. 

Notas: 

O DOM das Telas anterior e atual são carregados quando este evento é 

acionado. Para garantir que você está operando na tela que está sendo criada, execute a lógica apenas para o div elemento HTML com a classe activescreen. Mantenha essa ação do manipulador de eventos simples e evite usar Agregados de Tela ou Ações de Dados, que são executados em paralelo, para manipular dados que podem não estar disponíveis.Evite acessar os dados da Tela ou do Bloco, pois esta ação é executada antes que os dados sejam buscados. Se você precisar desenvolver alguma lógica nesses dados, use o manipulador de eventos On After Fetch do respectivo Aggregate ou Data Action. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Inicialize um componente de terceiros que precise do DOM. 
• Adicione ouvintes a um elemento DOM. 
• Defina o foco em um widget de entrada. 
• Adicione ouvintes ao objeto de janela JavaScript. 

On Render 

O manipulador de eventos On Render é executado após cada renderização da Tela ou Bloco, ou seja, sempre que a Tela ou Bloco é aberto (logo após a execução do manipulador de eventos On Ready) e após qualquer alteração dos dados da Tela. Nos Blocos, este evento acontece antes do mesmo evento da Tela ou Bloco pai. Você pode usar esse manipulador de eventos para atualizar um componente de terceiros, como uma barra de progresso. 

Notas: 

Evite alterar os dados de tela ou bloco, pois toda vez que esses dados são 

alterados, o evento On Render é acionado novamente e o aplicativo pode ser 

executado em um loop infinito. 

Mantenha essa ação de manipulador de eventos simples e evite ações lentas, como solicitações do servidor, pois isso pode atrasar a renderização da Tela ou do Bloco. Na primeira renderização da Tela ou Bloco evite acessar os dados da Tela ou Bloco, pois não há garantia de que os dados já foram buscados. Se você precisar desenvolver alguma lógica nesses dados, use o manipulador de eventos On After Fetch do respectivo Aggregate ou Data Action. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Atuar em uma alteração nos dados da Tela ou Bloco para atualizar um componente de terceiros. Os mesmos casos de uso do manipulador de eventos On Ready. 

On After Fetch 

O manipulador de eventos On After Fetch é executado logo após um Aggregate ou Data Action terminar de buscar dados. Como cada Agregação ou Ação de Dados tem seu próprio manipulador de eventos On After Fetch, você pode implementar a lógica para agir sobre os dados recuperados dessa fonte de dados. 

Notas: 

Quando o manipulador de eventos On After Fetch é executado, os dados chegam e estão disponíveis, mas não estão vinculados a widgets. Isso significa que os widgets ainda não foram atualizados. Casos de uso que você pode implementar com este manipulador de eventos: 

Atribua o primeiro ou último registro retornado pela consulta a uma variável. No padrão mestre-detalhe, para iterar uma consulta para preencher uma lista de listas. Para consultas dependentes de outras consultas, você pode usar esse manipulador de eventos para acionar o Agregado dependente.  

Casos de uso que você não deve implementar com este manipulador de eventos: 

• Não use a função GetUserId() neste momento para conhecer o usuário que está autenticado no momento. A execução paralela de Ações de Dados e Agregados do lado do cliente em uma Tela substitui o cookie de autenticação de sessão. Portanto, usar a função GetUserId() no evento On After Fetch pode retornar um valor vazio. 

On Parameters Changed 

O On Parameters Changed é um manipulador de eventos apenas para Blocos que são executados após a Tela ou Bloco pai alterar uma entrada do Bloco. Caso você tenha um Bloco dentro de outro Bloco e uma alteração de uma entrada do Bloco externo afete uma entrada do Bloco aninhado, o manipulador de eventos On Parameters Changed do Bloco externo é executado antes do mesmo evento do Bloco aninhado. Você pode usar este manipulador de eventos para adaptar o Bloco às alterações de parâmetros de entrada, como atualizar variáveis ou executar novamente Agregados e Ações de Dados. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Atualize um Agregado ou Ação de Dados que dependa desse parâmetro de entrada. 
• Recalcular uma variável que depende do parâmetro de entrada. 

On Destroy 

O manipulador de eventos On Destroy é executado quando a Tela ou Bloco vai ser destruído. Nas Telas, este evento acontece quando termina a transição para a nova Tela. Em Blocks, este evento acontece antes que o Block seja removido do DOM. Este evento é acionado seguindo uma ordem de cima para baixo: caso você tenha uma Tela com Blocos aninhados, o evento acontece primeiro na Tela, depois no Bloco externo e depois nos Blocos aninhados. Você pode usar esse manipulador de eventos para implementar a lógica para remover qualquer pegada da Tela ou do Bloco, como remover ouvintes de eventos. 

Notas: 

O DOM das telas presente e de destino é carregado quando este evento é 

acionado. Para garantir que você está operando na tela que está sendo destruída, execute a lógica apenas para o div elemento HTML com a classe activescreen. Mantenha essa ação do event handler simples e evite ações lentas como requisições do servidor, pois isso pode atrasar a remoção da Tela ou Bloco e, no caso de sair de uma tela, o carregamento da próxima tela. 

Casos de uso que você pode implementar com este manipulador de eventos: 

• Chame a ação de destruição de componentes de terceiros. 
• Limpe o DOM para executar um plugin novamente. 
• Remova os ouvintes JavaScript. 

Timers 

Um Timer é uma ferramenta da OutSystems que permite executar a lógica da aplicação periodicamente em um horário programado. Eles também são conhecidos como trabalhos em lote. 

Você pode usar Timers para executar lógica assíncrona em seu aplicativo OutSystems. Isso é útil para executar tarefas em lote, como enviar e-mails em um horário predeterminado, ou para executar lógica para configurar um aplicativo após sua implantação. 

Diferentes Timers podem ser executados ao mesmo tempo, mas o mesmo Timer nunca tem mais de uma execução por vez. 

Seguem-se alguns cenários comuns onde pode utilizar temporizadores: 

Trabalhos agendados: Execute o mesmo trabalho todos os dias no mesmo horário. Por exemplo, envie todos os dias às 4 da manhã e-mails para assinantes com notícias resumidas. Crie um Timer para executar uma Ação que faça o trabalho de enviar e-mails aos assinantes todos os dias às 4 da manhã 

Executando ações de longa duração: Execute a lógica do aplicativo que geralmente leva muito tempo para terminar. Por exemplo, às 2h do primeiro dia de cada mês, o sistema deve arquivar muitos registos do banco de dados. Demora cerca de 2 horas. Crie um Timer para executar uma Ação que arquive registos e configure-o para ser executado às 2h do primeiro dia de cada mês e com o tempo limite padrão de 150 minutos (este valor pode ser ajustado na Central de Atendimento). 

Arquitetura 

A lista a seguir mostra os elementos OutSystems relacionados aos Timers: 

Serviço OutSystems Scheduler: Este é o serviço que tem a responsabilidade de verificar se os Timers serão executados. É um serviço multi-threaded que permite ter diferentes Timers executando ao mesmo tempo. 

Banco de dados de tempo de execução: O banco de dados de tempo de execução contém todas as entidades do Sistema para gerenciamento de Timers, como: 

- O registro de todos os Timers existentes. 

- A programação para a execução de temporizadores. 

- Execução atual dos Timers: quando iniciados, seu tempo limite ou próxima execução. 

Banco de Dados de Log: Quando um Timer é executado, uma entrada é criada no banco de dados Log. 

Ferramenta de configuração: Esta é a ferramenta que permite configurar o número máximo de Timers que podem ser executados ao mesmo tempo em cada nó do servidor front-end. 

OutSystems Logs: No Service Center, você pode acessar os logs do Timer para aplicativos individuais ou todos os aplicativos em seu ambiente. 

Módulo implantado (aplicativo): O aplicativo implantado contém o código para o Timer. Possui a lógica da aplicação desenhada na Action executada pelo Timer, e também algum código stub necessário para atualizar o banco de dados do sistema sobre o estado do Timer. 

Como os temporizadores são executados 

O Scheduler Service é responsável por executar todos os Timers. Este serviço é multi-threaded, portanto, permite executar diferentes Timers ao mesmo tempo. Para simplificar, as etapas abaixo descrevem a execução de um único Timer. 

Os passos para executar os Timers são os seguintes: 

1. O Scheduler Service busca ciclicamente o banco de dados para que os Timers sejam executados ( Next_Run ). 
2. O Scheduler Service lança uma thread para executar o Timer que chama um Web Service no módulo onde está definido o Timer para executá-lo. 
3. O Web Service verifica primeiro se o Timer já está em execução em algum nó do Servidor Front-end. Caso contrário, os atributos Is_Running_Since e Is_Running_By da entidade Cyclic_Job_Shared são atualizados. Isso bloqueia a execução do Timer em qualquer outro nó de servidor front-end. 
4. O módulo executa a ação associada ao Timer. 
5. Após o término da execução da ação, os atributos Is_Running_Since e Is_Running_By são limpos, o que libera o Timer para uma nova execução. O atributo Next_Run é recalculado com base no atributo Schedule e na data e hora atuais. 

Em relação ao atributo Next_Run , ele é atualizado somente se não foi alterado durante a execução da ação. Isso pode acontecer se, por exemplo, a própria ação atualizar esse atributo. 

1. Um registro com as informações sobre a execução do Timer é enviado para o Log Service que o armazena no Log Database. 
2. O Web Service devolve o controle para o Scheduler Service, que agora fica pronto para executar outro Timer (passo 1.). 

Por que um tempo limite em Timers? 

Conforme descrito anteriormente, o Scheduler Service executa um Timer chamando um Web Service construído no módulo onde o Timer foi criado. Isso significa que existe uma Web Request envolvida na execução dos Timers e, como em qualquer Web Request, há um tempo máximo permitido para que ela seja executada no servidor. É por isso que os Timers possuem a propriedade 'Timeout em Minutos' no Service Studio, que por padrão está configurado para 20 minutos, mas você pode ajustar a cada caso. 

Gerenciando temporizadores no centro de serviços 

O Service Center disponibiliza um conjunto de funcionalidades que lhe permitem gerir os seus Timers, nomeadamente: 

• Monitore a execução dos Timers 
• Edite as configurações do temporizador 
• Forçar a execução de um Timer 
• Desativar/Ativar um Timer 
• Navegue pelos logs de execuções anteriores 

Monitorando a execução de Timers 

No Service Center, você pode monitorar a execução de seus Timers na opção Environment Health, em Monitoramento. A página possui uma seção de Timers com uma lista que mostra a ordem pela qual os Timers são executados. 

Os critérios para classificar os temporizadores na lista são baseados no seguinte: 

• A prioridade do temporizador. 
• O tempo que um Timer leva para ser executado, com base em sua duração anterior. Os temporizadores com tempos de execução mais rápidos são executados primeiro. 
• O tempo que um Timer está esperando para ser executado. À medida que o tempo de espera do Timer cresce, ele tende a subir na lista. 

Criar o temporizador 

Para criar um Timer em seu módulo, faça o seguinte: 

1. Na árvore do módulo, na guia Processo, clique com o botão direito do mouse na pasta Timer e selecione Adicionar Timer. 
2. Escolha a ação a ser executada quando o cronômetro for executado ou selecione (Nova ação do servidor) para criar uma ação. 

Se a Action que você especificar tiver parâmetros de entrada, ao criar o Timer, você precisará especificar os valores que serão passados ​​como parâmetros quando o Timer for ativado. Porém, se a ação possuir parâmetros de saída, não há como acessá-los após o término da execução da ação. 

Você pode definir um agendamento para executar o Timer automaticamente ou pode forçar o Timer a ser executado sem esperar pelo horário agendado. 

Definir a programação do temporizador 

Você pode definir a programação de um Timer de uma das seguintes maneiras: 

• Configurando a Schedule propriedade do Timer em tempo de design: Você pode definir uma programação recorrente, como diária ou semanal, ou definir o Timer para ser executado sempre que o módulo for publicado, por exemplo, para executar configurações ou dados de bootstrap. 

• Configurando a programação do Timer em tempo de execução no Service Center: Nos casos em que você precisa personalizar a programação do Timer ao implantar um aplicativo em outro ambiente, não há necessidade de alterar o aplicativo. A programação efetiva do Timer é definida no Service Center, que usa as configurações padrão em todos os ambientes, a menos que seja especificamente modificado. 
• Implemente a lógica que altera a programação do Timer em tempo de execução: atribua a Schedule propriedade de tempo de execução do Timer com uma programação específica dentro de sua lógica. Certifique-se de usar o formato de hora correto. 

Quando você define uma programação para seu Timer, o Timer será executado no horário predefinido. 

Forçar o Timer a funcionar 

Existem duas formas de forçar um Timer a funcionar sem esperar pela hora programada: 

• Usando a Wake<Timer Name>ação integrada 
• Executando o Timer no Centro de Serviços 

Nenhuma dessas opções altera a programação do timer, portanto, o Timer continuará funcionando normalmente. Além disso, como o mesmo Timer não é executado duas vezes simultaneamente, se você executar um Timer que já esteja em execução, a segunda execução só será iniciada após o término da primeira. 

Use a ação integrada do WakeTimer 

Quando você cria um Timer, uma ação integrada é fornecida para permitir que você execute o timer de forma programática. Essa ação é chamada Wake<Timer Name> e pode ser usada na lógica do seu aplicativo. 

Quando a Wake<Timer Name> ação é executada, a NextRun propriedade desse Timer é atualizada para o tempo atual. O timer será então tratado pelo Scheduler Server e executado de acordo com suas prioridades. 

A Wake<Timer Name>ação não recebe nenhum parâmetro de entrada e não retorna nenhum parâmetro de saída. 

Para usar a Wake<Timer Name> ação integrada em sua lógica, faça o seguinte: 

1. Na guia Processo, expanda o elemento Temporizador. 
2. Arraste a Wake<Timer Name>ação e use-a em sua lógica. 

Execute um cronômetro no centro de serviço 

Para forçar a execução de um Timer na Central de Atendimento, faça o seguinte: 

1. Na guia Factory , escolha Modules e encontre seu módulo. 
2. Na página de detalhes do módulo, escolha a guia Timers. 
3. Clique no Timer que deseja executar. 
4. Clique no botão Executar agora. 

Editando um Temporizador 

Você pode editar um Timer clicando no nome do Timer em um dos seguintes locais na Central de Serviços: 

• Módulo: edite o módulo onde está definido o Timer, selecione a aba Timers, e uma lista de Timers é exibida. 
• Registo de temporizadores: vá para a página de registo de temporizadores onde cada linha da lista tem o nome do temporizador. 
• Integridade do ambiente: vá para a página Integridade do ambiente, verifique a seção Timers onde cada linha da lista tem o nome do Timer. 

Desativando/ativando um temporizador 

Para interromper a execução de um Timer (obtido pelo Serviço Agendador e consumir recursos), pressione o botão Desativar na parte inferior da página. O Timer não será mais buscado pelo Serviço Agendador. Isso não interromperá um cronômetro em execução, apenas interromperá outras execuções. 

Se o Timer estiver desativado, o botão mostra Ativar e você deve pressioná-lo para que o Timer volte a funcionar. 

Autor: Thiago Mari - OutSystems Expert