Defining service definitions

Service definitions are a representation of the logic that regulates document workflow services.

The Service Builder is a graphical interface that enables you to create a graphical representation of these services, in the following situations:

  • Transporting data, typically between Sterling Order Management System Software and external applications
  • Transforming data from one format to another
  • Extending the application logic when events are raised

Services can be accessed by using the following mechanisms:

  • executeFlow() API
  • Resource configuration for accessing from the user interface
  • Actions can be associated to start a service
  • User-triggered transactions can be used to start a service to raise an alert to inform the applicable users
  • Document Routers
  • Monitors
Note: If you try to configure more than one action serially by using the Service Definition Framework, the Applications Manager displays an error message, "A continue link must be attached to the next condition or action." To avoid this error, group these actions and replace them with one service.

Service nodes

Service nodes contain the logic that you can use to build a service definition.

The following service nodes are available from the Service Palette:

  • Transport nodes
  • Component nodes
  • Adapter nodes
  • Connector nodes

Connector nodes are only available from the right-click menu.

Transport nodes

Transport nodes forward messages, allowing Sterling Order Management System Software to communicate with external systems. Transports (and the entire service) can be classified into the following categories:

  • Synchronous - Immediately forward messages
  • Asynchronous - Store and forward messages

You can add a transport node by dragging it from the pallet into the work area. For more information, see Transport nodes. You can use either synchronous or asynchronous transport type as needed for your business.

The synchronous services forward messages immediately. Sterling Order Management System Software supports the following synchronous transport types:

  • COM
  • Enterprise Java™ Bean (EJB)
  • Hypertext Transfer Protocol (HTTP)
  • Web Services
  • Synchronous IBM MQSeries Message Queue
  • Synchronous IBM MQSeries Message Topic
  • Synchronous Oracle WebLogic Message Queue
  • Synchronous Oracle WebLogic Message Topic
  • Apache Kafka

The asynchronous services store and forward messages. They queue up messages in a database or a queuing mechanism, which allows you to reprocess exceptions, if any, at a later time. Sterling Order Management System Software supports the following asynchronous transport types:

  • Asynchronous MQ JMS Queue
  • Asynchronous MQ JMS Topic
  • Asynchronous Oracle WebLogic JMS Queue
  • Asynchronous Oracle WebLogic JMS Topic
  • Database
  • File IO
  • FTP
  • Generic JMS
  • MSMQ

Each transport type has the following sender and receiver aspects:

  • receiver - defines how information should be received from the transport node
  • sender - defines how information should be sent to the transport

Whether a transport is a sender or receiver depends on how you have connected the flow of logic to be directed.

Component nodes

Component nodes format or translate data. Sterling Order Management System Software supports the following components:

  • Alert
  • API
  • E-Mail
  • Composite Service
  • Condition
  • Nomenclature Runtime
  • Router
  • Text Translator
  • XSL Translator

You can add a component node by dragging it from the pallet into the work area.

Adapter nodes

Adapter nodes allow you to implement a Sterling Order Management System Software Adapter with an external system.

Sterling Order Management System Software supports the IBM® Sterling B2B Integrator.

Connector nodes

Connector nodes allow you to link nodes together without adding any additional logic. This allows you to complete a service. The types of available connector nodes are as follows:

  • Start node - All services are required to begin with a Start node. The Start node defines where to begin running the Service Definition Framework logic. When you create a new flow, the Start node is already laid out for you.
  • End node - All services are required to end with an End node. The End node defines where to end that particular flow of the Service Definition Framework logic. When you create a new flow, the End node is already laid out for you.
  • Pass-through node - The Pass-through node allows you connect synchronous and asynchronous components together.

You can add a connector node by right-clicking in the work area and selecting from the connector node types.

Criteria of a complete service flow

The following conditions must be met in order to save a service:

  • Start node - Required. One maximum.
  • Transport node - Optional. Zero or many.
  • Component node - Required. One or many.
  • Adapter Node - Optional. Zero or many.
  • End Node - Required. One or many.
  • All nodes must be connected.
  • All required properties on all nodes and links must have values that are specified.