Monday, January 6, 2020

12c SOA - Oracle Mediator part10 - Java Callout

  • Java Callout is used when we need to have certain validation or want to manipulate the message. We need to implement the oracle.tip.mediator.common.api.IjavaCallout interface to use below defined function for Java Callout.
  • The Java Callout is invoked by the Mediator on a number of times, prior to and after performing the Routing Rule and each of the cases in it. The Java Callout class can implement a number of methods, one for each specific event or stage in the Mediator process. These methods get access to the input message as well as the transformation result. That means that the callout class can inspect, validate, log, audit and even manipulate these messages, their payloads, headers and properties.
We have below methods in the oracle.tip.mediator.common.api.IjavaCallout interface.

Initialize : This method is invoked when the callout implementation class is instantiated for the first time.
preRouting : This method is called before Mediator starts executing the cases. You can customize this method to include validations and enhancements.
preRoutingRule : This method is called before Mediator starts executing any particular case. You can customize this method to include case-specific validations and enhancements.
preCallbackRouting: This method is called before Mediator finishes executing callback handling. You can customize this method to perform callback auditing and custom fault tracking.
postRouting : This method is called after Mediator finishes executing the cases. You can customize this method to perform response auditing and custom fault tracking.
postRoutingRule: This method is called after Mediator starts executing the cases. You can customize this method to perform response auditing and custom fault tracking.
postCallbackRouting: This method is called after Mediator finishes executing callback handling. You can customize this method to perform callback auditing and custom fault tracking.

UseCase 1: Using a postRouting method, the javacallout will log the response in the soa_server.log/out file.

Implementation:

Create a SOA project and open a mediator component
Select Synchronous interface.

Call a synchronous service


Create a Java class
Add oracle.tip.mediator.common.api.IjavaCallout interface


Modify the postRouting method
    public boolean postRouting(CalloutMediatorMessage calloutMediatorMessage,
                               CalloutMediatorMessage calloutMediatorMessage2,
                               Throwable throwable) throws MediatorCalloutException {
        System.out.println("Mediator has invoked Java Callout; executing postRouting");
        String sPayload = "null";
        for (Iterator msgIt = calloutMediatorMessage2.getPayload().entrySet().iterator();msgIt.hasNext(); ) {
          Map.Entry msgEntry = (Map.Entry)msgIt.next();
          Object msgKey = msgEntry.getKey();
          if (msgKey.equals("reply")) {
              Object msgValue = msgEntry.getValue();
              sPayload = XmlUtils.convertDomNodeToString((Node) msgValue);
              System.out.println("Mediator sends reply: " + sPayload);
          }
        } //for
        return true;
    }

Select the created class from call out section

Map the request and response



Deploy and test




Sample class for modifying the input request:
public boolean preRouting(CalloutMediatorMessage calloutMediatorMessage) throws MediatorCalloutException {
        System.out.println("Pre routing...");
        String sPayload = "null";
        String sPayload_changed = "null";
        for (Iterator msgIt = calloutMediatorMessage.getPayload().entrySet().iterator();          msgIt.hasNext(); ) {
            Map.Entry msgEntry = (Map.Entry)msgIt.next();
            Object msgKey = msgEntry.getKey();
            if (msgKey.equals("request")) {
                Object msgValue = msgEntry.getValue();
                sPayload = XmlUtils.convertDomNodeToString((Node)msgValue);
                try {
                    XMLDocument xmlpayload = XmlUtils.getXmlDocument(sPayload);
                    NodeList node = xmlpayload.getChildNodes();
                    Node item = node.item(0);
                    System.out.println("the value of the request element = " +
                                       item.getTextContent());
                    sPayload_changed = sPayload.replaceAll(item.getTextContent(),
                                                "changed text");
                    XMLDocument xmlpayload_changed =
                        XmlUtils.getXmlDocument(sPayload_changed);
                    String mykey = "request";
                    calloutMediatorMessage.addPayload(mykey,
                                                      xmlpayload_changed);
                    System.out.println("Mediator sends request: " +
                                       sPayload_changed);
                } catch (Exception e) {
                    System.out.println(e);
                }
            }
        }
        return true;
    }

Thursday, January 2, 2020

12c SOA - Oracle Mediator part9 - Write a XML file using file adapter


Here i will show how to write a XML file to a local directory.

First create a Schema.
 Open a composite project and select mediator and used the schema.

 Drag and drop the File adapter
 setup the configurations.



 Here I mentioned .txt, you can also make it .xml and other extension needed.
 choose same schema or can use different schema



 Open the mediator and do the transformation





Deploy and Test.


12c SOA - Oracle Mediator part8 - Schematron or Payload validation

Schematron Basics:
  • Schematron is an XML schema language, and it can be used to validate XML contents in an XML payload. Schematron defines a set of rules and checks that are applied to an XML instance. 
  • Schematron relies almost entirely on XPath query patterns for defining these rules and checks. 
  • The schematron validation allows loose coupling of Semantic validation of the incoming/outgoing mediator payload.This is accommodated while defining the routing rule for mediator payloads.
  • The Schematron file is created with a file type having an .sch extension.
Schematron Structure:
  • A Schematron XML document consist of a schema element in the Schematron namespace: http://www.ascc.net/xml/schematron
  • The schema element contains one or more pattern elements. Pattern elements allow the user to group schema constraints logically. Some examples of logical groupings are: Text Only Elements, Valid Root Element, Check for ID Attribute. Pattern elements have a name attribute. 
  • Rule elements define a collection of constraints on a particular context in a document instance (for example, on an element or collection of elements). This is very similar to XSLT templates, which are fired with respect to a node or group of nodes returned by an XPath expression.
  • The Schematron standard defines two types of rules: assert and report. The assert rule returns your error message when the test condition fails (returns false), whereas the report rule returns your error message when the test conditions succeeds (returns true). The Schematron implementation in the SOA Suite only supports the assert rule, so you have to rewrite your report rules. This is not much of a problem, because the assert rule is just the logical complement (inversion) of the report rule, so the logical “not” function solves this issue. In case of just a logical comparison in the test condition, you also can invert it by replacing a = operator, etc.
The namespaces of our input payload (“http://www.emp.org”) have to be declared. The solution is to use the “ns” element with attributes “uri” and “prefix”:
<ns uri="http://www.emp.org" prefix="emp" />

XSD used:
<?xml version="1.0" encoding="windows-1252" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.emp.org" targetNamespace="http://www.emp.org"
            elementFormDefault="qualified">
  <xsd:element name="Employees">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="Employee" maxOccurs="unbounded">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="Name" type="xsd:string"/>
              <xsd:element name="Id" type="xsd:integer"/>
              <xsd:element name="Salary" type="xsd:integer"/>
              <xsd:element name="Type" type="xsd:string"/>
              <xsd:element name="ManagerName" type="xsd:string"/>
              <xsd:element name="ManagerId" type="xsd:integer"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>
</xsd:schema>

 Schematron created:
<?xml version="1.0" encoding="UTF-8" ?>
<schema xmlns="http://www.ascc.net/xml/schematron">
    <ns uri="http://www.emp.org" prefix="emp" />
    <pattern name="Employee may not be the manager of himself">
        <rule context="/emp:Employees/emp:Employee">
            <assert test="emp:Id != emp:ManagerId">Employee may not be the manager of himself</assert>
        </rule>
    </pattern>
    <pattern name="Validate Employee Type">
        <rule context="/emp:Employees/emp:Employee">
            <assert test="emp:Type = 'PERM'">Not a permanent employee</assert>
        </rule>
    </pattern>
</schema>
Rule1: if Emp id != manager id condition fails then it throws the error "Employee may not be the manager of himself"
Rule2: if EMp type = 'PERM' fails then it throws the error "Not a permanent employee".

Double Click on the Mediator component. Check the ‘Validate Syntax (XSD)’ option. Click on the image icon at ‘Validate Semantic’ and use the schematron.sch file for Schematron validation.







Deploy and test.
Tested with keeping the following:
-Employee1 is TMP type
-EMployee2 is sharing same id with manager.

Error details:
The selected operation execute could not be invoked.
A fault occurred while invoking the webservice operation. The fault is : <env:Fault xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode>env:Server</faultcode>
<faultstring>oracle.tip.mediator.infra.exception.MediatorException: ORAMED-01301:[Payload custom validation]Schematron validation fails with error "<ns1:ValidationErrors xmlns:emp="http://www.emp.org" xmlns:ns1="http://xmlns.oracle.com/pcbpel/validationservice">
<error>Employee may not be the manager of himself</error>
<error>Not a permanent employee</error>

</ns1:ValidationErrors>
".Possible Fix:Fix the payload.</faultstring>
<faultactor/>
<detail>
<exception/>
</detail>
</env:Fault>



oracle.sysman.emInternalSDK.webservices.util.SoapTestException: Client received SOAP Fault from server : oracle.tip.mediator.infra.exception.MediatorException: ORAMED-01301:[Payload custom validation]Schematron validation fails with error "
Employee may not be the manager of himself
Not a permanent employee

Featured Post

11g to 12c OSB projects migration points

1. Export 11g OSB code and import in 12c Jdeveloper. Steps to import OSB project in Jdeveloper:   File⇾Import⇾Service Bus Resources⇾ Se...