| Oracle® Communications IP Service Activator OSS Integration Manager Guide Release 7.2 E36051-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications IP Service Activator OSS Integration Manager Guide Release 7.2 E36051-01 |
|
|
PDF · Mobi · ePub |
This appendix illustrates how to use Oracle Communications IP Service Activator External Object Model (EOM) events that are generated by IP Service Activator OSS Integration Manager (OIM) on TransactionEntry objects. The sample OSS Java Development Library (OJDL) code, shown on "Sample OJDL file" and explained with examples "Coding examples", transforms the EOM events into Java Message Service (JMS) events, which are then published on a JMS topic.
The events are meant to be used by an external JMS-enabled application to track the activation status of its IP Service Activator transactions. Activation status information in IP Service Activator is available for all transactions through TransactionEntry's ProvisioningStatus and ReasonForFailure attributes.
Changes to these two attributes, as well as TransactionEntry's State attribute, are encoded in the JMS messages and can be easily decoded by the external client. The format of the messages can also be customized.
Two types of JMS events are generated: TransactionCreation and AttributeChange. These events are described in the following sections.
This event is generated when a transaction is created by an IP Service Activator client. The transaction for the generated create event is treated as active in the sample. All active transactions are stored in a container, so that subsequent events on them can be analyzed and translated into AttributeChange events.
This event is generated when one or more attributes of an active transaction change. The event indicates that one of the following has occurred:
Transaction's State attribute changed. This is an indication that a scheduled transaction has been merged into the IP Service Activator object model and its activation has begun.
Transaction's ProvisioningStatus attribute changed. Three cases are possible:
Transaction's ProvisioningStatus changed to Success. This is an indication that directly committed or scheduled transaction completed activation successfully.
Transaction's ProvisioningStatus changed to Failed. This is an indication that directly committed or scheduled transaction has failed activation. The same event should contain new value for the ReasonForFailure attribute.
Transaction's ProvisioningStatus changed to Timedout. This is an indication that activation status of directly committed or scheduled transaction was not confirmed during the configured timeout period.
Note:
If AttributeChange is generated and indicates that ”Transaction's State attribute changed” occurred, it is followed by another AttributeChange indicating that any one of the three cases of ”Transaction's ProvisioningStatus attribute changed” occurred.
An AttributeChange indicating any one of the three cases of ”Transaction's ProvisioningStatus attribute changed” is the final event for a transaction.
There is a code example available in the additional documentation included with the OJDL libraries. For more information, see the example ”SampleTransactionStatusPublisher” in the ojdlSamples folder of the OJDL zip package. Various parts of the sample file are explained in the section "Coding examples".
The following examples illustrate how the code in the OJDL sample file (shown starting on "Sample OJDL file") can be used to transforms the OSS Integration Manager (OIM) events on TransactionEntry objects into Java Message Service (JMS) events.
In this section, OSS Integration Manager (OIM) events are defined as events generated by the IP Service Activator OIM. OJDL clients poll for those events by calling EomSession.getEvents.
Implements the run() method of Runnable. The run() method executes an infinite loop that is only interrupted when the application exits. It repeatedly calls
getEomEvents()
The returned events are then processed:
for (int i = 0; i < events.length; i++) {
System.out.println(events[i]);
processEomEvent( events[i]);
}
The run method pauses before repeating the same cycle:
Thread.sleep( IPSA_EVENT_POLLING_INTERVAL);
A real transaction publisher will be executing the run method on a separate thread concurrently with other activities.
An EOM session is used in order to obtain OIM events:
events = m_eomSession.getEvents(false);
The session is reestablished when exceptions occur (for example due to IP connectivity loss):
// reconnection attempt System.err.println(”Re-attempting to establish EOM session to host: ” + IPSA_HOST + ” port: ” + IPSA_PORT + ”. Attempt # ” + numAttempts); openEomSession();
Up to [IPSA_NUM_RECONNECT_ATTEMPTS] attempts are made to reestablish a failed session
for( int numAttempts = 0; numAttempts <= IPSA_NUM_RECONNECT_ATTEMPTS; ++numAttempts) {
...
System.err.println(”Re-attempting to establish EOM
session to host: ” + IPSA_HOST +
” port: ” + IPSA_PORT + ”. Attempt # ” + numAttempts);
openEomSession();
...
}
Create events on TransactionEntry objects are recognized using a pattern matcher and processed in the onCreateEvent() method:
...
Matcher createEomEventMatcher =
createEomEventPattern.matcher( eomEvent);
...
if( createEomEventMatcher.find()) {
onCreateEvent( createEomEventMatcher);
}
The onCreateEvent () method stores a record of the transaction being created (referred to as active transaction):
m_activeTransactions.put( infoObject.Id, infoObject);
Next, it formats the text of the outgoing JMS message and calls publishJmsMessage().
Modify events on active transactions are recognized using a pattern matcher and processed in the onModifyEvent() method:
Matcher modifyEomEventMatcher =
modifyEomEventPattern.matcher( eomEvent);
...
else if( modifyEomEventMatcher.find()) {
onModifyEvent( modifyEomEventMatcher, eomEvent);
}
The onModifyEvent method makes sure that the event is on an active transaction before processing it:
if( m_activeTransactions.containsKey( objectId)) {
...
}
The onModifyEvent method uses four patterns and matchers to match changes on the following attributes: ScheduleTime, State, ReasonForFailure, and ProvisioningStatus.
In addition to the new value, the old value of the attribute is retrieved from the stored info object. Both values are used to format an attribute change clause in the text of the outgoing JMS event. More than one attribute change clause can occur in the same JMS event. This would typically be the case when the event indicates Provisioning Status changed to failed. The same event will contain ReasonForFailure.
All attribute change clauses are concatenated to form the text of the outgoing JMS message passed to publishJmsMessage().
The sample uses templates for the text of both TransactionCreate:
protected final String createEventTemplate = ”TransactionCreation(\n” + ”Id: \”%Id%\”,\n” + ”Name: \”%Name%\”,\n” + ”NumberOfConcretes: \”%NumberOfConcretes%\”,\n” + ”ScheduleTime: \”%ScheduleTime%\”,\n” + ”State: \”%State%\”\n” + ”)\n”;
and AttributeChange events:
protected final String attributeChangeEventTemplate = ”AttributeChangeEvent(\n” + ”Id: \”%Id%\”,\n” + ”Name: \”%Name%\”,\n” + ”%AttributeChanges%)\n”;
There is also a template for a single attribute change:
protected final String attributeChangeTemplate = ”%AttributeName%: ( \”%OldValue%\”, \”%NewValue%\”)\n”;
These templates contain markers in the format %markername% which are replaced with the actual values. The templates can be changed to any desired format. For example, you can change the templates so that the messages conform to a particular XML schema or DTD.
The JMS message is published from within the publishJmsMessage:
TextMessage message = m_jmsSession.createTextMessage(); message.setText(messageText); m_jmsPublisher.publish(message);
The sample uses a JMS topic to publish the message. This may be changed to a queue if the receiver is using a queue.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|