Usando saídas de usuário para estender transações padrão

O Sterling™ Order Management System oferece a capacidade de estender ou substituir os principais algoritmos de negócios. Isso é feito por meio de saídas de usuário que são chamadas quando os algoritmos são executados.

Uma saída de usuário típica pode:
  • Substituir a lógica de aplicativo fornecendo sua própria lógica.
  • Estender a lógica de aplicativo fornecendo mais entradas para o algoritmo do aplicativo.

Por exemplo, se um pedido é dividido em diversas remessas, você pode precisar calcular o preço do pedido diferentemente para cada remessa. ] Para mudar a maneira como o Sterling Order Management System calcula os preços de ordem, é possível substituir o cálculo ou algoritmo específico na saída de usuário repriceOrder

Cada saída de usuário é uma interface Java™ separada.. Você pode escolher implementar somente as saídas de usuário nas quais desejar substituir ou aumentar a lógica de negócios.

Nota: quando a API ou transação acionada por tempo está executando o algoritmo padrão, a saída de usuário é chamada. Se a sua implementação da função lançar uma exceção, a transação atual será retrocedida.
Para obter descrições detalhadas de cada saída de usuário, consulte os seguintes pacotes Javadoc:
  • com.yantra.ycm.japi.ue
  • com.yantra.ycp.japi.ue
  • com.yantra.ydm.japi.ue
  • com.yantra.yfs.japi.ue

Implementando saídas de usuário

Todas as classes de saída de usuário devem ser implementadas como um arquivo JAR que esteja disponível no caminho de classe do script do adaptador de agente e no arquivo smcfs.ear implementado no seu servidor de aplicativos.

Diretrizes para saídas de usuário

As seguintes diretrizes devem ser mantidas em mente quando você estiver usando Saídas de Usuário dentro da API do aplicativo:
  • Saídas de Usuários são estruturadas para retornar informações específicas e, assim, seu uso deve ser restrito para esse propósito sozinho.
  • A partir das saídas de usuário, não é possível chamar APIs que modifiquem os dados. Isso é para garantir que erros não ocorram devido aos dados que estão sendo modificados na transação-pai (a transação que chama a saída de usuário), e aos mesmos dados que estão sendo modificados no código customizado da saída de usuário. Por exemplo, não é possível chamar uma API changeOrder() de uma saída de usuário que obtenha informações relacionadas ao mesmo pedido.

Porém, APIs que não modificam os dados (como APIs de seleção) podem ser chamadas nas saídas de usuário. Por exemplo, é possível chamar a API getOrderDetails() de uma saída de usuário.