Deploying Client Adapter

Processing requests to the application flow

OSS/J Order Management (JMS Profile) Client Adapter is built around the Protocol Message Flow (PMF) framework, using a limited number of modules.

To receive and process requests an ossjomemsca::ClientAdapter must be deployed in the Fulfillment Provisioning application flow and configured using the ossjomemsca::Config using the Client Adapter framework.

The Client Adapter should be configured with the request processing PMF which is delivered within the OSS/J Order Management Client Adapter. This PMF mainly contains an OrderManagementModule which processes the requests. This PMF can be shared among different OSS/J Client Adapters.

The ossjomemsca::Config includes the following parameters:

User Parameter Description
applicationContext_URL

A user configuration parameter containing the applicationContext.URL that keys show Default: “”

applicationDN

The applicationDN.

Default: OSS_APPLICATION_DN

All the EMS connectivity parameters are configured with one string passed to NETEMS as is usually done with NETMANCA based client adapters.

This EMS network address is as follows: 

MULTIEMS:Common:tcp://TMP_EMS_HOST:TMP_EMS_PORT/destinationKind=queue,userName=admin,passwo
rd=not,ackMode=auto|!
MessageQueue:/sessionKind=receiver,destination=tibco.fos.fp.ossj.OrderManagement.MessageQue
ue|XVTEventTopic:/sessionKind=sender,destinationKind=topic,destination=tibco.fos.fp.ossj.Or
derManagement.XVTEventTopic

Where:

  • MessageQueue is the message queue to poll for requests
  • XVTEventTopic is the topic where to send notifications

Sending notifications from the application flow

If some events are sent by the Client Adapter processing the requests, some events must be sent from the Fulfillment Provisioning application flow. In order to do that, a user should deploy ossjomemsca::ClientAdapter in the Fulfillment Provisioning application flow and configure it to use the notification PMF.

This notification PMF mainly contains the ossjomemsca::NotificationProducer module which is able to send a list of events at immediately, depending on the incoming ServiceOrder content.

Such a notification Client Adapter has its own connection pool, and can be deployed at several places in the application flow. The three most interesting places are:

  • After KOP to send a RequestAttributeValueChangeEvent
  • After POP to send a RequestAttributeValueChangeEvent
  • At the end the application flow to send a RequestStateChangeEvent

ll the EMS connectivity parameters are configured with one string passed to NETEMS as is usually done with NETMANCA based client adapters.

This EMS network address is as follows: 

MULTIEMS:Common:tcp://TMP_EMS_HOST:TMP_EMS_PORT/destinationKind=queue,userName=admin,passwo
rd=not,ackMode=auto|!
XVTEventTopic:/sessionKind=sender,destinationKind=topic,destination=tibco.fos.fp.ossj.Order
Management.XVTEventTopic

Where XVTEventTopic is the topic where notifications are sent.

The connection identifiers must not be changed. The destinations can however be changed to whatever meaningful value. The NotificationProducer accepts several user definable ServiceOrderData::NVSet parameters.

Parameter Description
Generic Parameters
ossj.events.length

Indicates the number of events that are going to be sent

Type: long

ossj.events.[i].type

The type of the i-th event where [i] should be replaced with the event index

Type : enum

{ RequestAttributeValueChangeEvent, RequestStateChangeEvent }

RequestStateChangeEvent Parameters
jssj.events.[i].reason The reason of the state change

For example, in order to send a RequestAttributeValueChangeEvent followed by a RequestStateChangeEvent, the WorkSimulator of the delivered example does the following in CES: 

FORMAT:<ossj.events.length>=2
FORMAT:<ossj.events.0.type>=RequestAttributeValueChangeEvent
FORMAT:<ossj.events.1.type>=RequestStateChangeEvent
FORMAT:<ossj.events.1.reason>=order fulfilled

An example of client adapter deployment is delivered at:

$SW_HOME/distrib/kabira/kpsa/samples/ca/ossjomems/ex00

File Description
README Self description file
driver_config.ini

A sample configuration file for the driver client adapter

responder_config.ini

A sample configuration file for the responder (notification producer)

config.ini Fulfillment Provisioning config.ini file
WorkSimulator.ces A CES file acting as work simulator
example.env Example implementation based on caexample
caexample.kes The deployment specification of the example

fp.kds

Deployment specification embedding caexample.kes
fp.xml Fulfillment Provisioning application flow – XMI format

The example only configures and starts the client adapter. It requires an EMS daemon running and configured properly. The README gives details on how to do that.

This example must be run with the help of the caexample plugin: 

Admin configure caexample example=ossjomems/ex00
Admin start caexample example=ossjomems/ex00
To stop the example, perform the following: 
Admin stop caexample example=ossjomems/ex00