Process Oracle OER Events using a simple Web Service

This post provides an example of a simple web service that processes Oracle Enterprise Repository (OER) Events.
The service receives events from OER and utilizes the OER REX API to implement simple OER
automations for selected event types.

The web service example implements the following:


The sample web service is not intended to replace the out of the Box OER BPM Based workflows,
but the service can be utilized in cases where only simple automation is required and the developer has a Java skill set.

Deployment
          Diagram

The service is a lightweight web application that can be easily deployed to the same server as OER or on a different server.

The complete code is available at GitHub here.


Building the sample Service

                                    Project_Properties



Configure OER to enable the OER Event Manager and dispatch events every 5 seconds

Login to the OER web application as the Admin user.

Under the OER main Admin menu  choose  System Settings

Set the  'cmee.eventframework.enabled'  property value to True
Set the  'cmee.eventframework.delivery.sleep'  property value to 10 seconds to have OER delivery events every 10 seconds.
Save the changes by pressing the save button.


Configure OER to call this custom web service when events are raised in OER

Edit the EndPointEventSubscription.xml file located in the deployed OER application (stage directory)
for example
${middleware}/user_projects/domains/soa_domain/servers/gov_server1/stage/oer_11/oer_11.1.1.5.0/oer-app/WEB-INF/classes/

Update the values of the host, port and uri elements to match your local environment.
These settings tell OER where the custom Event Service is deployed.
OER will send events to this service endpoint when events are raised in OER.

 <sub:endPoint name="ALBPMEndpoint">

                        <!--The host of the Webservice Endpoint -->
                        <sub:host>localhost</sub:host>
                       
                        <!--The port of the Webservice Endpoint -->
                        <sub:port>7001</sub:port>
                       
                        <!--The URI of the Webservice Endpoint -->
                        <!--If you are using ALBPM5.7 uncomment the following line and comment the line after -->
                        <!-- <sub:uri>fuegoServices/ws/StatusChangeEndpointServiceListener</sub:uri> -->
                        <sub:uri>OEREvents-OEREventService-context-root/eventService</sub:uri>
                       
                        <!--Unless a custom WSDL Contract is used, the namepsace should not be changed -->
                        <sub:targetNamespace>http://www.bea.com/infra/events</sub:targetNamespace>


Save the file and restart the Weblogic Server hosting OER

Once the OER Event manager is enable, dispatched events should be visible in the event log file.
${wls_domain_home}/cmee.log 
Monitor the Event Log File, using tail -f or some other method.



Testing the Service sample automations

Once the custom event service has been deployed and the OER is configured to call the service,
the serviceit can be tested by Manually adding  new Service and Interface Assets to the repository.

Create a New Service Asset
Login to the OER Web Application as the admin user and start the Asset Editor by
clicking the 'Edit / Manage Asset' link in the left navigation pane.

Choose the File->New   menu option.
The 'Create a new Asset' dialog should appear.
In the name field, enter the value:           {example.com/v1.0}SuperService
Leave the Version field empty
In the type drop down field select:          Service
Set the Initial State drop down field to:    Unsubmitted

New Service

Press the OK button to close the dialog.
A Message dialog should appear with the message      '"{example.com/v1.0}SuperService" has been created.

Create a New Interface Asset

Login to OER as the admin and start the Asset Editor by
clicking the 'Edit / Manage Asset' link in the left navigation pane.
Choose the File->New   menu option.
The 'Create a new Asset' dialog should appear.
In the name field, enter the value:           {example.com/v1.0}/interface/SuperService
Leave the Version field empty
In the type drop down field select:            Interface
Set the Initial State drop down field to:    Unsubmitted

New_Interface

Press the OK button to close the dialog.
A Message dialog should appear with the message
 '" {example.com/v1.0}/interface/SuperService" has been created.


Add a relationship between the Service and the Interface

Select the Service named   {example.com/v1.0}SuperService   in the Asset editor.
Select the Taxonomy tab and scroll to the   'Relationships'  section
Click the 'Add' button
Set the Relationship Type drop down type to    'Contains'
Press the Search button and select
      {example.com/v1.0}/interface/SuperService
from the Find Assets to Relate list.

Press the Ok button to add the relationship.
Select File->Save from the Asset Editor main menu.


Test and Review Automation Results

Testing involves two phases,

  1. Submitting the draft Assets for Acceptance
    The AssetSubmissionHander should auto accept the asset.
    The AssetAcceptedHandler should assign the accepted asset to a define user.

  2. Registering the SuperService for reuse
    The RelatedAssetRegisterHandler should register the corresponding SuperService interface.


Submit the Super Service.

Ensure the Asset Editor is currently editing the {example.com/v1.0}SuperService' and the Administration tab is active.
Press the Submit button to submit the Asset.

Submit the Super Service Interface
Ensure the Asset Editor is currently editing the {example.com/v1.0}/interface/SuperService' and the Administration tab is active.
Press the Submit button to submit the Asset.

Automation results will take a few seconds depending on the the rate that events are delivered by OER.
Within a minute:

                                      The user that accepted the asset is defined by the 'event.AssetSubmission.acceptor' property in the
                                      applications EventHandlerConfig.properties file.

                               The assigned user is defined by the 'event.AssetSubmission.assignee' property in the
                               applications EventHandlerConfig.properties file.
                                

Accepted
            Asset


Version


Register the Super Service

The final test is to register the SuperService.
Ensure the Asset Editor is currently editing the {example.com/v1.0}SuperService' and the Administration tab is active.
Press the Register button to register the asset for reuse.
The Registered Field on the SuperService Admin tab should show the user and time of the registration.

Switch the Asset Editor to point to the  interface Asset     {example.com/v1.0}/interface/SuperService   
After a few seconds the related Interface Asset should also be registered as shown below.
It may be necessary to select View->Refresh Tree from the Asset Editor main menu several times
before the changes become visible.


Registered
              Interface



Repeating Tests


Repeated testing can be performed by resetting the state of the submitted assets.

Reset the Service Asset State by doing the following:
Edit the Service Asset in the Asset Editor and select the Administration tab.
Select the Assigned user and press the delete button
Press the Unregister button.
Press the UnAccept button to unaccept the asset.
Press the UnSubmit button to unsubmit the asset.

Reset the Interface Asset State by doing the following:
Edit the Interface Asset in the Asset Editor and select the Administration tab.
Press the Unregister button.
Press the UnAccept button to unaccept the asset.
Press the UnSubmit button to unsubmit the asset.


Initiate a new test by pressing the "Submit" button on the Service Asset


Service Development Overview


The following instructions highlight the major development steps.

Prepare the Service WSDL

The service implements the Event Service WSDL that ships with the OER product.
In the OER 11.1.1.5 distribution the wsdl file can be found in the
${OER_HOME}/oer_11.1.1.5.0/oer-app/WEB-INF/lib/modules.eventing-11.1.1.5.0.jar  archive.

The wsdl contains a number operations that not needed and the complete wsdl has some validation issues.
Modify the wsdl so it contains only the 'newEventRequestResponse' operation.
The modified wsdl is also included in the completed project on GitHub


Create a new Application using JDeveloper

Implementation of the service is too detailed for step by step notes.
Please download the completed service from GitHub at the above link.
The following steps provide a rough overview of the implementation steps performed

From the JDeveloper main menu selected
Application->New Generic Application:   'OEREvents'
With New Generic Project:                         'OEREventService'

Right clicked on the newly created OEREventService project and choose
Business Tier-> Web Services-> Java Web Service From WSDL

In Wizard
Selected Java EE 1.5 with support for JAX-WS RI
Browsed and selected modified WSDL as discussed above.
Leave Java selected
Leave Add Service Endpoint Interface UNselected
Leave Copy WSDL Locally selected

Set Package Name:               com.example
Set Root Package for types: com.example.types

Pressed Next and Finish
(Code Generation takes approximately 1 minute)




Implementing the Service

The following steps provide a rough overview of the implementation steps performed

Added the Service implementation code to the EventPortTypeImpl.java file.
The supplied code uses a strategy pattern to dispatch each event to a specialized Handler class.
The configured Java handler class for the event is loaded dynamically and invoked when events are received.

Created a com.example.eventhandlers folder
Created a Handler class that implements the EventHandler interface for each event type
of interest received from OER.
Configured the new handler for the event in the EventHandlerConfig.properties file

The service utilizes the Apache commons logging. 
The included property file is set to add the service log entries to the WebLogic Server log file.