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.