Orquestração de pedidos: serviços de decomposição

Após um pedido ter sido validado com sucesso, a decomposição do pedido é a próxima etapa no processo de orquestração do pedido O processo de decomposição é acionado por uma validação bem-sucedida de um pedido O aplicativo IBM Sterling® Order Management System utiliza um conjunto de serviços para realizar a decomposição de pedidos.

A lista de serviços usados no processo de decomposição de orquestração de ordem é a seguinte::
Tabela 1. Lista de serviços utilizados no processo de decomposição de orquestração de pedidos
Nome do Serviço Descrição
TriggerDecomp Serviço para atender a mensagem recebida do serviço de validação ou acionado para tentar novamente O processo de validação envia as informações necessárias para o processo de decomposição chamando o serviço TriggerDecomp . O serviço TriggerDecomp chama a API customizada ProcessOrderDecomp.
ProcessOrderDecomp A API customizada que executa o processo de decomposição A API customizada que prepara a entrada para a solicitação de decomposição e chama as regras de negócios usando o serviço InvokeDecompRules , bem como processa a resposta de decomposição do mecanismo de regras.

A API ProcessOrderDecomp chama as APIs getOrderDetails e getItemList para obter as informações completas do pedido usando um modelo extensível, getOrderDetailsForDecomposition. A saída das duas saídas API é combinada em um documento.

A saída da API ProcessOrderValidation é enviada para o serviço de mapeamento, PrepareMappingForDecomp que pode ser implementado para transformar o XML em um formato entendido pelo mecanismo de regras.

PrepareMappingForDecomp Esse serviço de mapeamento de item temporário é fornecido para transformar dados de pedido em um formato entendido pelo mecanismo de regras para criar a solicitação de decomposição..

Após a mensagem de decomposição ser preparada, o serviço InvokeDecompRules é chamado.

InvokeDecompRules API customizada para criar entrada para decomposição e chamar mecanismo de regras usando um serviço comum, InvokeBusinessRule. Esse serviço constrói a solicitação final com cabeçalho e dados.
O elemento de saída do InvokeDecompRules deve ser o seguinte:
<DecompOrderList OrderHeaderKey=“RootOrderKey” OrderNo=“RootOrderNo” EnterpriseCode=“Required”>
    <Order CustomerPONo=”{root OrderNo}” ShipToKey="{root ShipToKey}" ShipToID="{root ShipToID}" BillToKey="{root BillToKey}"
           BillToID="{root BillToID}" SellerOrganizationCode="{root SellerOrganizationCode}" OrderNo="Required" 
           OrderType=“ResourceOrder|ServiceOrder|ProductOrder” OrderDate="" EnterpriseCode="{root EnterpriseCode}" 
           DraftOrderFlag="N">
        <OrderLines>
            <OrderLine PrimeLineNo=“” SubLineNo=”” OrderedQty=“”>
                <Item UnitOfMeasure="" ProductClass="" ItemID=" "/>
                <CustomAttributes/>
            </OrderLine>
        </OrderLines>
        <ParentOrder OrderNo=“Required”/>
        <CustomAttributes/>
    </Order>
.
.
.
</DecompOrderList>

Elementos necessários em negrito e elementos entre colchetes ({}) devem ser fornecidos. Se @OrderType não for transmitido, ele será padronizado para ProductOrder. Se qualquer atributo não for transmitido, mas puder ser padronizado a partir da ordem pai, como @DocumentType, @EnterpriseCode e @BillToID, esses atributos serão buscados da ordem pai.

ProcessDecompResponse Chama multiApi para criar pedidos e relacionamentos.. Uma API customizada obtém a saída do mecanismo de regras e chama a API do createOrder para cada um dos pedidos filhos O atributo @OrderType pode ser usado para a determinação de pipeline Antes de chamar a API createOrder, uma lógica padrão preenche todas as informações básicas ausentes usando a ordem original

Um mapa de relacionamento é criado a partir do documento de saída do mecanismo de regras e da saída da createOrder API, que conecta o OrderHeaderKeys dos pedidos criados com o OrderNo fornecido de cada pedido. Esse mapa de relacionamento é usado para chamar multiApi para criar os relacionamentos entre os pedidos

Os relacionamentos pai-filho são criados usando as informações disponíveis no elemento <ParentOrder> A ordem original é definida como a ordem de nível raiz e os pedidos podem especificá-la ou outra ordem na saída como seu pai.. Se o pai de um pedido não for especificado, ou o pedido listar a si mesmo como seu próprio pai, o pai para o pedido será padronizado para o nível raiz.

O <ParentOrder> e o @OrderNo devem fazer referência a uma ordem na saída do mecanismo de regras Se a ordem à qual se refere não puder ser localizada, uma exceção será lançada. E se houver uma dependência cíclica, como ordem filha-> primeiro pai-> segundo pai-> ordem filha, uma exceção será lançada.. O XML do elemento Order é o mesmo que o XML de createOrder e pode conter quaisquer elementos dessa API, com a inclusão do elemento <ParentOrder> necessário

PostMsgToBuildPlanQ Serviço para postar mensagens na fila de execução ou plano de construção.

Visualizando serviços de decomposição

Para visualizar os serviços de decomposição, execute as seguintes etapas:
  1. No menu Console do aplicativo , clique em Configuração > Ativar Applications Manager. O Gerenciador de Aplicativos é aberto em uma nova janela.
  2. No menu, clique em Aplicativos > Application Platform.
  3. Na árvore no painel lateral de regras do aplicativo, dê um clique duplo em Modelagem de Processo A janela Modelagem de Processo é exibida na área de trabalho.
  4. Selecione a guia Ordem de Vendas para visualizar a árvore de modelagem de processo correspondente para esse tipo de documento base..
  5. Na raia Tipos de Processo, clique com o botão direito no tipo de processo Ordem de Vendas e escolha Processo de Modelo. A janela Detalhes do Repositório e a área de trabalho para o tipo de processo.
  6. Escolha a guia Definições de Serviço e expanda o grupo de serviços Decomposição