Oracle SOA Suite 12c – Create, Deploy, Attach and Configure a Custom OWSM Policy – to report on service execution

9
Share this on .. Tweet about this on TwitterShare on LinkedIn13Share on Facebook1Share on Google+0Email this to someoneShare on Tumblr0Buffer this page

This article describes how to develop a straightforward custom assertion that can be used as part of custom OWSM policy to be attached to Web Services in WebLogic, such as services exposed by SOA Composite applications and Service Bus projects as well as custom JAX-WS or ADF BC Web Services. The custom assertion that I demonstrate here reports the execution of web service operations to a JMS Destination and/or the system output. It shows how to access property values set on the policy binding (values specific for the service the policy is attached to) and how to inspect the headers and contents of the request and response messages. Most custom assertions will use a subset of the mechanisms shown in this example. As always, the source code is available for download. Note: this article was edited on April 6th to reflect better code structure.

Custom assertions can be used in policies that are applied to web services. Depending on the type and configuration of the policy and assertions, they can be triggered at different moments and perform different tasks. These assertions are similar to aspects (in AOP) that take care of cross cutting concerns and that do not interfere with the internals of a service. Policies are attached (and detached) at runtime by the administrators. The assertion discussed in this article is to be attached to the service binding at the inbound end of a SOA composite application (or at a Service Bus proxy service that serves the same purpose). The assertion will report every incoming request as well as each response returned from the service binding. This information can be leveraged outside the scope of this article to monitor the runtime service environment.

The steps describes in this article in the process of creating and putting into action the custom assertion are:

  • Create Custom Policy:
    • Assertion Java Class
    • Policy XML File
    • Policy Configuration XML File
  • Deploy Policy Artifacts to Runtime Fusion Middleware platform (and restart the WebLogic Servers)
  • Import Policy Definition into Runtime Fusion Middleware platform
  • Attach the Policy to a Service Binding in an existing SOA Composite application and configure the policy binding properties
  • Invoke the service exposed by the [Service Binding in the existing] SOA Composite application
  • Verify the results produced by the policy attachment

Create the Custom Policy

The main part of the custom assertion definition is a Java class. See for details the sources that can be downloaded from GitHub.The project contains a helper class – CustomAssertion – that takes care of some generic plumbing that are required for the AssertionExecutor superclass that needs to be extended. The class SOASuiteServiceExecutionReporter contains the custom logic that is to be executed whenever the policy assertion is triggered. In the current case, this logic consists of retrieving some key elements about the service request – service name, operation name, ECID, timestamp and selected payload details – and reporting them. Initially, this report consists of a few lines in the system output (i.e. the domain log file). Later on, we will send the report to a JMS destination.

The init() method is invoked by the OWSM framework when the policy is attached to a web service and whenever the configuration of the policy attachment is updated (i.e. its property values are changed). The init() method reads and processes the policy attachment configuration and initializes the SOASuiteServiceExecutionReporter, priming it for the correct actions whenever service executions trigger its execute method.

image

This code snippet relies heavily on the super class (CustomAssertion ) that returns the values for the properties from the iAssertion.

image

It also leverages the method initializeMessageTypesMapFromJson. This method performs the parsing of the operationMap property in the policy binding configuration. The properties are defined in the policy definition file – see below – and are set to binding specific values in the EM FMW control (or from WLST).

Properties can be simple string values. By using JSON snippets for the values of these properties, we can pass quite complex and extensive data structures into the policy attachment. In the current case, we use a JSON style property to specify for a policy binding which message types are processed ; each message type is a key in the JSON object and for each message type are defined: the name of the operation, an indication of the operation one-way is and an XPath expression to derive a value from the message payload to be reported.

This JSON structure looks like this- here message type getFlightDetailsRequest is mapped to operation getFlightDetails; from the request message, the value of element /soap:Envelope/soap:Body/flig:getFlightDetailsRequest/flig:FlightCode/com:CarrierCode should be reported:

image

The parsing of the JSON property is done using standard JSON-P support in this case, in the helper class ServiceReporterSettings:

image

In this code snippet, the JSON structure of the operationsMap property is parsed, interpreted and turned into a corresponding set of Java Objects. The data structures and class definitions are outlined in the next illustration:

image

 

 

The Execute method – processing every service execution

The execute method is invoked when the service receives a request or returns a response or a fault. The method gets passed in an IContext object. This object provides access to most relevant details about the request or response message – including the complete SOAP Envelope and the Transport Headers. Note that the GUID attribute contains the FMW ECID attribute value; the value is the same for the request message and the corresponding response (or fault) message.

image

 

One aspect of the custom assertion is the determination of the message type that is handled. The message type is read from the SOAP Body:

image

Here we use the getDataNode() helper method that is used to execute XPath queries against the mBody element, to derive the first child node within the SOAP Body.

When payload elements are to be extracted, this is done in a similar fashion:

image

The report on the service execution is created like this:

image

The policy can be attached to one service or  – more common – to may services. Each policy attachment (aka policy binding) can be configured with property values that are specific for the service and how the policy should act in the context of the service.

The file SOASuiteServiceExecutionReporterPolicyFile.xml contains the definition of the custom policy. This file is deployed to the runtime environment and also uploaded to the FMW Control, as we will see later on. This file defines the policy, its meta data including its properties etc.

image

The file policy-config.xml is another link in the chain. It joins the policy definition from the previous file with the Java Class.

image

 

 

Deploy Policy Artifacts to Fusion Middleware Infrastructure

Create a deployment profile (simple Java Archive) for the JDeveloper project. Deploy the project to a JAR file using this profile.

image

Copy JAR file to the WLS DOMAIN\lib directory (download the jar-file).

Using the target information in the EM FMW Control, I find out about the exact the file location for the WebLogic domain that hosts the SOA Suite:

image

the lib directory under this domain home is where the jar file should be moved.

Restart the WebLogic domain.

 

Import Policy Definition into Fusion Middleware Infrastructure

Start EM FMW Control.

image

navigate to Web Logic Domain – soa_domain | Web Services | WSM Policies.

Click on Import

image

Import zip file with appropriate structure (this means it should contain a folder structure of META-INF\policies\some-custom-folder-name\policyname.xml:

image

by clicking on Import

image

and selecting the right zip file:

image

The report back:

image

and the policy is listed:

image

Details:

note that the policy is enabled, local optimization is off and the policy applies to service bindings (not SCA components, although that could be an option too) and is in the category Service Endpoint

image

and on the assertion:

image

The policy is ready for attachment to service bindings.

 

Attach Policy to SOA Composite Service Bindings

Open the SOA Composite, such as the FlightService composite shown below. Click on the Service Binding to which the policy is to be attached:

image

Open the Policies tab:

image

Click on the button Attach/Detach to open the dialog where policies can be attached to the service binding.

image

Select the amis/monitoring policy. Click on Attach to bind this policy to the service binding.

Click on OK to confirm the policy attachment.

Click on Override Policy Configuration to set the property values that apply specifically to this policy attachment:

image

The properties that are defined in the policy configuration file – SOASuiteServiceExecutionReporterPolicyFile.xml – are listed and the current values are shown. These values can now be overridden for this attachment of the policy to the FlightService.

image

Click on Apply to confirm the property values.

At this point, the policy is primed for action for the FlightService.

Test the Custom Policy Activity

By invoking the various FlightService operations, we can now see the policy in action.

image

The effect of this call is reported by the custom policy in the log-file:

image

A call to another operation results in a similar report:

image

in the log file:

 

image

Note: even services to which the policy is attached without any additional configuration override will have their execution reported. However, these reports obviously cannot report the operation name (only the message type) nor any values from the payload. Here a report from the ConversionService that has the policy attached – without any configuration.

image

Resources

JSON parsing in Java – http://www.oracle.com/technetwork/articles/java/json-1973242.html and http://docs.oracle.com/javaee/7/api/javax/json/JsonReader.html.

Documentation for Fusion Middleware 12c (12.1.3)

Developing Extensible Applications for Oracle Web Services Manager –  http://docs.oracle.com/cd/E57014_01/owsm/extensibility/owsm-extensibility-create.htm#EXTGD153

Overriding Policy Configuration Properties – http://docs.oracle.com/cd/E57014_01/owsm/security/override-owsm-policy-config.htm#CACGHIFE

Managing Web Service Policies with Fusion Middleware Control – http://docs.oracle.com/cd/E57014_01/owsm/security/manage-owsm-policies.htm#OWSMS5573

XML Schema Reference for Predefined Assertions – http://docs.oracle.com/cd/E57014_01/owsm/security/owsm-assertion-schema.htm

Stepping Through Sample Custom Assertions – https://docs.oracle.com/middleware/1213/owsm/extensibility/owsm-extensibility-samples.htm#EXTGD162

Share this on .. Tweet about this on TwitterShare on LinkedIn13Share on Facebook1Share on Google+0Email this to someoneShare on Tumblr0Buffer this page

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director and Oracle Developer Champion. Solution architect and developer on diverse areas including SQL, JavaScript, Docker, Machine Learning, Java, SOA and microservices, events in various shapes and forms and many other things. Author of the Oracle Press books: Oracle SOA Suite 11g Handbook and Oracle SOA Suite 12c Handbook. Frequent presenter on community events and conferences such as JavaOne, Oracle Code and Oracle OpenWorld.

9 Comments

  1. Hi Lucas,

    Thanks, This is very helpful.

    I followed these steps and created custom policy for authentication of restful proxy web services and successfully imported it inside em; but I am facing the below error while attaching the authentication policy in service bus console.
    I found the same error reported in known issues but I could not fix it,
    http://www.oracle.com/technetwork/middleware/soasuite/documentation/soaknown-2644661.html
    bug number 16894883.

    Any help is appropriated.

    [OSB-398128]One of the Web service policy attached is not allowed on service SBCustomPolicyDemo/RestService because the service binding does not support it

  2. Hi Daniel, where did you read about OSB not supporting custom assertions? I ask that because I need to create a customo assertion for a customer using OSB (masking some data). Cheers!

  3. Daniel Sitnik on

    Hi Lucas.
    Great article, I have successfully implemented a custom policy by following your guidelines and attached it to SOAP proxies.

    However, I have not been able to apply it to SOAP business services and REST proxies/business. Please, do you know if this approach is supported for these kinds of services?

  4. Hi all,
    I’m looking for an ID that identify a request/response interaction. ECID is the same for any interactions that are involved in a flow but i want to distinguish them. If exists, can i get it from the ImessageContext?

    Thanks,

    DI

    • Lucas Jellema on

      Hi Davide,

      I am not sure this information is available from the messageContext. There are the identifiers you can find in the Enterprise Manager and in the underlying tables in the SOA Infra database but I doubt whether this information is in the messageContext. After all – this message context is not specific to SOA Suite/SOA Composite interactions.

      Lucas

Leave a Reply