Definindo definições de serviço

As definições de serviço são uma representação da lógica que regula os serviços de fluxo de trabalho do documento.

O Service Builder é uma interface gráfica que permite criar uma representação gráfica desses serviços, nas situações a seguir:

  • Transporte de dados, normalmente entre o Sterling™ Order Management System e aplicativos externos
  • Transformando dados de um formato para outro
  • Estendendo a lógica do aplicativo quando os eventos são gerados

Os serviços podem ser acessados por meio dos seguintes mecanismos:

  • executeFlow() API
  • Configuração de recurso para acessar a partir da interface com o usuário
  • As ações podem ser associadas para iniciar um serviço
  • As transações acionadas pelo usuário podem ser usadas para iniciar um serviço e gerar um alerta para informar os usuários aplicáveis
  • Roteadores de Documentos
  • Monitores
Observação: Se você tentar configurar mais de uma ação em série usando a Estrutura de definição de serviço, o Gerenciador de aplicativos exibirá uma mensagem de erro: "Um link de continuação deve ser anexado à próxima condição ou ação" Para evitar esse erro, agrupe essas ações e substitua-as por um serviço

Nós de serviço

Os nós de serviço contêm a lógica que você pode usar para construir uma definição de serviço

Os nós de serviço a seguir estão disponíveis na Paleta de Serviço:

  • Nós de transporte
  • Nós do componente
  • Nós do adaptador..
  • Nós do conector

Os nós do conector estão disponíveis apenas no menu ativado pelo botão direito.

Nós de transporte

Nós de transporte encaminham mensagens, permitindo que o Sterling Order Management System se comunique com sistemas externos. Os transportes (e o serviço inteiro) podem ser classificados nas seguintes categorias:

  • Síncrono - Encaminhar mensagens imediatamente
  • Assíncrono - Armazenar e encaminhar mensagens

É possível incluir um nó de transporte arrastando-o do palete para a área de trabalho. Para obter mais informações, consulte Nós de transporte. Você pode usar o tipo de transporte síncrono ou assíncrono, conforme necessário para seus negócios.

Os serviços síncronos encaminham as mensagens imediatamente. O Sterling Order Management System suporta os seguintes tipos de transporte síncronos:

  • COM
  • Bean Java™ empresarial (EJB)
  • HTTP (Protocolo de Transporte de Hipertexto)
  • Serviços da web
  • IBMMQ Fila de mensagens
  • IBM síncronas MQ Tópico da mensagem
  • Apache Kafka

Os serviços assíncronos armazenam e encaminham mensagens. Eles enfileiram mensagens em um banco de dados ou em um mecanismo de enfileiramento, que permite reprocessar exceções, se houver, posteriormente. O Sterling Order Management System suporta os seguintes tipos de transporte assíncronos:

  • Fila JMS assíncrona do MQ
  • Tópico JMS Assíncrono do MQ
  • Banco de dados
  • E/S do Arquivo
  • FTP
  • JMS Genérico
  • MSMQ

Cada tipo de transporte possui os seguintes aspectos de emissor e receptor:

  • receptor-define como as informações devem ser recebidas do nó de transporte
  • emissor-define como as informações devem ser enviadas para o transporte

Se um transporte é um emissor ou um receptor depende de como você conectou o fluxo de lógica a ser direcionado

Nós do componente

Nós do componente formatar ou converter dados. O Sterling Order Management System suporta os seguintes componentes:

  • Alerta
  • API
  • E-Mail
  • Serviço Composto
  • Condição
  • Tempo de Execução de Nomenclatura
  • Roteador
  • Conversor de Texto
  • Conversões de XSL

É possível incluir um nó de componente arrastando-o do palete para a área de trabalho

Nós do adaptador..

Os nós do adaptador permitem implementar um Adaptador do Sterling Order Management System com um sistema externo.

OSterling Order Management System suporta o IBM® Sterling B2B Integrator.

Nós do conector

Os nós do conector permitem vincular nós juntos sem incluir nenhuma lógica adicional. Isso permite concluir um serviço. Os tipos de nós do conector disponíveis são os seguintes:

  • Nó inicial-Todos os serviços são necessários para iniciar com um nó inicial. O nó Inicial define onde iniciar a execução da lógica do Service Definition Framework. Ao criar um novo fluxo, o nó Inicial já está definido para você.
  • Nó de extremidade-Todos os serviços são necessários para terminar com um nó de extremidade. O nó de Extremidade define onde terminar esse fluxo específico da lógica do Service Definition Framework. Ao criar um novo fluxo, o nó de extremidade já está definido para você.
  • Nó de passagem-O nó de passagem permite conectar componentes síncronos e assíncronos juntos.

Você pode adicionar um nó conector clicando com o botão direito do mouse na área de trabalho e selecionando um dos tipos de nó conector.

Critérios de um fluxo de serviço completo

As condições a seguir devem ser atendidas para salvar um serviço:

  • Nó inicial-necessário. Um máximo.
  • Nó de transporte-Opcional Zero ou muitos.
  • Nó do componente-necessário. Um ou muitos.
  • Nó do Adaptador-Opcional Zero ou muitos.
  • Nó Final-Necessário. Um ou muitos.
  • Todos os nós devem estar conectados.
  • Todas as propriedades obrigatórias em todos os nós e links devem ter valores especificados.