This article shows how using the Service Execution Reporting policy – first introduced in this article: https://technology.amis.nl/2015/04/01/oracle-soa-suite-12c-create-deploy-attach-and-configure-a-custom-owsm-policy-to-report-on-service-execution/ – and the bridge created from the reporter through JMS to Stream Explorer – demonstrated in this article: https://technology.amis.nl/2015/04/06/live-monitoring-of-soa-suite-service-execution-with-stream-explorer-leveraging-custom-owsm-policy-and-jms/ – we can create a business monitor. The reports on service executions can be interpreted in a functional way to produce business insight.
In this article we will specifically monitor airplanes at the gate – an example inspired by the Saibot Airport case in the Oracle SOA Suite 12c Handbook. Clearly, the time at the gate should be minimized. We will keep an eye on planes that remain at the gate for too long.
When a flight opens at the gate – the sendFlightStatusUpdate operation on the FlightService is invoked. Subsequently, as the flight starts boarding, has completed boarding and is closed (and departs), the same operation is invoked. The new status is reported to the service and routed onwards by the service to interested parties.
Using the Service Execution Reporter policy, we report calls to the sendFlightStatusUpdate operation and make sure that carrier, flight number and the new status are included in the report. In Stream Explorer, we create a Stream for consuming the service execution report messages from a JMS Queue. The Stream Explorer [data] shape contains properties for carrier, flight number and status. An exploration is based on the stream – filtering only on reports from the sendFlightStatusUpdate operation on the FlightService.
When this exploration is tested, we create a second exploration based on the missing event detection pattern. This exploration will detect cases where the report of a flight changing its status to open (at the gate, starting the departure procedure) is not followed quickly enough by a report of that same flight changing its status to closed. When this situation is detected, it is reported – and action can be taken.
We will see how we change the status of several flights to open in a short period of time. Then, for all but one of the flights, we change the status to closed. The Stream Explorer exploration will report the one flight for which the status was not updated [in time], proving that we can perform such business monitoring.
A video illustrating the end result achieved in this blog article is available from YouTube.
Configure Service Execution Reporter policy for the sendFlightStatusUpdate operation
We will assume here that the policy has been added to the SOA Suite runtime as is described in this article – by adding the JAR file and importing the policy description.
The policy needs to be attached to the FlightService and the configuration needs to be overridden to cater for the sendFlightStatusUpdate operation. This is done in the EM FMW Control. Select the FlightService SOA Composite. Click on the FlightService Web Service binding. Open the Policies tab. Attach the amis/monitoring policy. Click on the link to Override Policy Configuration, as shown in the next figure.
The Security Configuration Details popup appears. Here we can specify the values of the policy properties as they should be in the context of the FlightService. Make sure that the operationsMap property is set with the right configuration regarding the sendFlightStatusUpdateRequest message type and the associated sendFlightStatusUpdate operation.
Press Apply to save the changes.
Call the sendFlightStatusUpdate operation for example from SoapUI:
and verify whether the report is written to the log file as expected:
Apparently, the messages required to perform monitoring on flights that do not leave the gate soon enough are available on the JMS Queue. Let’s harvest and analyze them from Stream Explorer.
Create the Stream Explorer Stream and Exploration
Open Stream Explorer. Create a Stream for the JMS Queue to which the Service Execution Reporter publishes messages. Note: remove any existing streams on top of this queue to prevent the streams from competing for the queue’s messages.
The wizard for a new Stream opens.
Set the name and a description for the stream.
Then click Next.
Configure the JMS queue details:
And press Next.
Define the Shape (the data structure to capture the values from the MapMessages on the JMS Queue):
and define all properties – using the names of the properties written to the MapMessage:
Finally, click Create.
The wizard to create the Exploration appears. Define a name and a description:
Click on Next.
Define no special filters, aggregation or time constraints to just report all reports. Now make a few calls to the sendFlightStatusUpdate operation. Each call should produce a service execution report message that shows up in the exploration:
Create the Pattern Based Exploration to Detect Missing ‘flight closed’ Messages
The exploration we need now is one that is based on the Detect Missing Event pattern. The missing event in this case is the report of a status update to ‘closed’ for a flight (carrier plus number) that was reported as being ‘opened’ – within the specified time. In a normal airport, we would perhaps use 40 minutes as the maximum period. In this demo case, we will use 40 seconds as the cut off time.
First of all, we need to publish the exploration AllServiceExecutionReport – in order to use it as the source for our next exploration:
From this exploration we will siphon off the messages that relate flight status updates in a new exploration FlightStatusOpenAndClosedUpdateReports.
Configure filters to focus on messages from service default/FlightService/FlightService and where operation equals sendFlightStatusUpdate and stage equals request.
Note: I would have wanted to add a filter on status open or close. However, Stream Explorer does not let me create such a filters at the present time.
Publish this exploration:
The challenge I have to address at this point is: identify cases where the status of a flight is updated to open and where there is not subsequent update of the status of that same flight to closed within 40 seconds. While there is no exact fit, this sounds very much like to the Detect Missing Event pattern that Stream Explorer supports. I will create an exploration based on that pattern to see how close I can some to implementing my requirement.
Now create another new Exploration – of type Pattern:
Configure the Exploration – set a name, select FlightStatusOpenAndClosedUpdateReports as the input stream. Select the fields businessAttribute1 , 2 and 3 – for carrier, flightnumber and status respectively – as the Tracking Fields and set the Heartbeat Interval to 40 seconds.
.
And at this point you probably realize that this is not entirely the correct pattern to detect. What we have specified here is that we want to get notified whenever it takes more than 40 seconds for a message with certain values for businessAttribute1, 2 and 3 to be followed by another message for the same values for the three business attributes. However, we want to raise the alarm only if there is not a message with status (businessAttribute3) closed within 40 seconds of a message with status open for a specific flight, identified by businessAttribute1 and 2. And this is a type of missing event detection that is one step too complex for Stream Explorer to handle. Its missing event detection pattern focuses on the simple case of a message with specified indicators that is not succeeded by a message with exactly the same set of indicators.
However, Stream Explorer brought us quite a long way. And it allows us to export the exploration – as an OEP application that can be imported into JDeveloper to be refined through normal OEP development. In JDeveloper, we can make a fairly small change that will turn the exploration into an OEP application that does exactly what we need it to do.
Export the Exploration:
Click on the Export link in the wizard page:
And save the file:
Open JDeveloper. Create a new, empty application – for example of type Custom Application.
Click on File | Import:
and select the option OEP Bundle into new project:
Select the file exported from Stream Explorer earlier on:
And the project is created from the JAR file:
Inspect the sources that were created by Stream Explorer. One processor for each exploration. The final one with the CQL logic for detecting missing events:
It is in this CQL query that we need to make some changes to achieve the functionality we desire. The CQL query is updated to detect specific situations where a flight status update event that reports the ‘open’ status is not followed – within 40 seconds – by a flight status update event that updates the flight to ‘closed’:
This rather small change is all it takes to take the Stream Explorer application and refine it to the point where it fulfills our needs.
The partition is defined by businessAttribute1 and 2 (carrier and flight number). The PATTERN is composed from event OPEN and event NOT_CLOSED. OPEN is defined as a flight status update with status is ‘open’. NOT_CLOSED is any message that does not indicate a ‘closed’ status for the same flight. Normally there would not be such a message. However, every 40 seconds, a timer event is added. This event satisfies the NOT_CLOSED condition. When the timer event comes sooner than the desired ‘closed’ status update, the pattern is satisfied and a result is produced.
In order to verify the effects of this change, I add a CSV Outbound Adapter to write the results to a file:
I then create a deployment profile for the project and deploy the OEP bundle to the OEP server – the same one that also runs Stream Explorer or a different one.
From SoapUI, I then send messages that set the flight status to open for a number of flights:
The file to which the results are written is almost empty:
I close a number of the flights, but not all of them:
One flight remains open. Will the OEP application detect the flight that was not closed within 40 seconds?
Of course it does:
