É possível melhorar o desempenho
configurando o número de listeners no adaptador e o número
de instâncias adicionais no fluxo de mensagens para evitar atrasos ao
processar chamadas síncronas a partir de SAP.
O adaptador de entrada SAP recebe chamadas síncronas do SAP. O adaptador possui uma propriedade chamada
Número de listeners, que controla o número máximo de chamadas
simultâneas, configurando o adaptador para ter um número específico de encadeamentos atendendo ao ID do
programa SAP. Os listeners enviam os parâmetros de entrada destas chamadas para o nó
SAPInput para processamento e os parâmetros de saída são enviados
para o nó SAPReply.
Quando o listener recebe uma chamada de SAP, ele bloqueia o processamento
até uma instância de fluxo de mensagens que contém o nó SAPInput estar disponível.
Quando uma instância do fluxo de mensagens ficar disponível e começar a processar os parâmetros de
importação, o listener bloqueará novamente o processamento até que uma mensagem que contenha os parâmetros de
exportação seja propagada para um nó SAPReply.
A quantidade de tempo que decorre entre o nó SAPInput que envia a mensagem
e o nó SAPReply que recebe
a mensagem de resposta pode ser afetada pela propriedade de instâncias adicionais
no fluxo de mensagens. Para evitar atrasos no processamento, ajuste o número máximo de listeners e o número de instâncias adicionais
para o fluxo de mensagens que contém os nós SAPInput e
SAPReply. É possível configurar
o número de instâncias adicionais no nível do fluxo de mensagens ou no próprio nó SAPInput.
Restrições
O número de listeners é limitado pela configuração do SAP. Em SMQS de
transação SAP, é possível visualizar e alterar a propriedade do máximo de conexões para cada destino RFC.
A configuração de um número de listeners maior que o número máximo de conexões não tem efeito.
Para
cada instância adicional do fluxo de mensagens, são usados recursos extras por cada nó no fluxo, dependendo
dos tipos de nós no fluxo.
Cenários
O diagrama a seguir ilustra um cenário básico, no qual o número de
listeners é igual ao número de instâncias adicionais do fluxo de mensagens; neste caso, o cenário foi
configurado com três listeners e três instâncias do fluxo de
mensagens.
- O SAP faz três chamadas, cada uma é recebida por um listener.
- Cada um dos listeners envia os parâmetros de entrada de cada chamada para o nó
SAPInput em uma de três instâncias do fluxo de mensagens.
- Cada instância do fluxo de mensagens envia sua mensagem para o aplicativo de destino.
- O aplicativo de destino processa as mensagens e retorna respostas às instâncias do fluxo de mensagens.
- O nó SAPReply em
cada instância de fluxo de mensagens envia a mensagem de resposta ao listener
que recebeu a chamada original.
- Cada listener retorna a mensagem de resposta ao programa SAP apropriado.
O nó
SAPReply pode estar no mesmo fluxo de
mensagens que o nó
SAPInput, conforme ilustrado no exemplo
anterior. No entanto, no cenário a seguir, o nó
SAPReply está em
um fluxo diferente do nó
SAPInput.
O nó
SAPReply deve ser implementado
no mesmo grupo de execução que o nó
SAPInput.
- O SAP faz três chamadas, cada uma das quais é recebida por um listener
diferente.
- Cada um dos listeners envia os parâmetros de entrada de cada chamada para um fluxo de mensagens que
contém um nó SAPInput.
- O fluxo de mensagens coloca a mensagem em uma fila para o aplicativo de destino.
- O aplicativo de destino obtém as mensagens da fila e processa-as.
- O aplicativo de destino coloca as mensagens em uma fila.
- Um segundo fluxo de mensagens que contém um nó SAPReply obtém
as mensagens da fila e processa-as.
- O nó SAPReply envia as mensagens de resposta para os listeners
apropriados.
- Cada listener retorna uma mensagem de resposta ao programa SAP apropriado.
Neste cenário, o fluxo de mensagens tem baixa latência em comparação com o tempo gasto pelo cenário
inteiro. Portanto, é possível limitar os recursos usados pelo fluxo de mensagens que contém o nó
SAPInput, configurando menos instâncias adicionais para este fluxo
de mensagens. Uma instância do
fluxo de mensagens, como no exemplo, pode servir vários listeners porque
o fluxo de mensagens propaga os parâmetros de importação rapidamente para processamento.
Os cenários a seguir
também são possíveis.
- Um único fluxo de mensagens contém um nó SAPReply, mas ele é
usado para responder a vários nós SAPInput.
Quando a mensagem tiver sido propagada para o nó SAPReply, o
listener retornará a resposta ao SAP e, portanto, estará pronto para receber outra chamada do SAP. No
entanto, a instância atual do fluxo de mensagens ainda está ocupada processando o recebimento de dados dos
nós do nó SAPReply. Neste caso, aumente o número de instâncias no
fluxo de mensagens que contém o nó SAPReply.
- Após a propagação para o nó SAPReply, outros nós no fluxo de
mensagens executam processamento extra. Neste caso, aumente o número de instâncias no fluxo de mensagens que
contém o nó SAPReply, mesmo quando ele for o mesmo fluxo que
contém o nó SAPInput.
Este cenário pode ter um efeito
indesejado na integridade de seus dados. Se
ocorrer uma exceção após o nó SAPReply, os recursos que
são atualizados pelo fluxo de mensagens (por exemplo, tabelas de banco de dados ou filas do WebSphere MQ) poderão ser retrocedidos.
No entanto, a resposta já foi retornada ao SAP e não pode ser retrocedida. Se este comportamento não for apropriado, será possível melhorar a integridade de dados assegurando que o nó
SAPReply seja o nó final no fluxo de mensagens.
Para obter informações sobre como ajustar o adaptador SAP, consulte Ajustando o Adaptador SAP para Escalabilidade e Desempenho.