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 Selling and Fulfillment Foundation and external applications
  • Transforming data from one format to another
  • Extending the application logic when events are raised

Services can be accessed using the following mechanisms:

  • executeFlow() API
  • Resource configuration for accessing from the user interface
  • Actions can be associated to invoke a service
  • User-triggered transactions can be used to invoke 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 using the Service Definition Framework, the Applications Manager throws 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 Selling and Fulfillment Foundation 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 may use either type, depending on your needs. The following sections list the types of synchronous and asynchronous transport types.

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

Synchronous services forward messages immediately. Sterling Selling and Fulfillment Foundation supports the following synchronous transport types:

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

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 Selling and Fulfillment Foundation 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 Selling and Fulfillment Foundation 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 Selling and Fulfillment Foundation Adapter with an external system.

Sterling Selling and Fulfillment Foundation 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 above 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 together.
  • All required properties on all nodes and links must have values specified.