Archive Page 2

Branching in Native REST Services

In previous post, we are introduced to native REST services (Typed and Un-typed) support in 12.2.1. But we can observe following issues there:

  • We used only GET method for demonstration and typically this would not be the case as REST service can also support other HTTP methods (POST, PUT and DELETE).
  • No branching in Typed REST Services when multiple HTTP methods are supported.
  • No branching in Un-Typed REST Services when multiple HTTP methods are supported.

In this post, we will try to cover above aspects. Note that all of this discussion is related to native REST services unless stated otherwise.

Branching in Typed REST Services:

Add POST method support for typedEmployees resource as shown below.





Since Typed REST Service uses WADL and contains Operation name annotated with soa:name, we can simply make use of Operational Branch.


You can use URL like below to access REST Service.


Branching in Un-Typed REST Services:

Since Un-Typed REST services does not use WADL, we can’t use Operational Branch as above. So in this release, OSB introduced a new node called  REST Branch for this purpose.


Add REST Branch in pipeline by dragging it from Components.


For each REST branch, give supported Media Types, Resource Path and HTTP method mandatorily.


Use + icon to add media types and give other information as shown below. This means we are creating a REST resource called  untypedEmployees which supports GET and supported media types are  application/xml, application/ json.


Modify REST branch name in General section of Properties. We can add more branches using highlighted icon below.


We can add POST method support for same resource path as shown below.




Test Proxy as shown below. Note that we had specified required parameters in HTTP headers.



You can use URL like below to access this REST Service and make sure that Content-Type is passed without fail.



  • OSB parses payload based on  HTTP header Content-Type in request. We can Use Log activity to see $body contents. Refer  to this post to enable logging.
  • When Content-Type is application/xml, $body is logged as below.

PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: <soapenv:Body xmlns:soapenv="http://schemas.">[[<a><b>1233333</b></a></soapenv:Body>]]

  • When Content-Type is application/json, $body is logged as below.

[PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: <soapenv:Body xmlns:soapenv=" soap/envelope/">{"a":1234,"b":3455}</soapenv:Body>

  • OSB binds a globally-scoped object called process and can be used as process.body or process.var which is similar to $body and $xyz XPath variables. This notation is used for Java Script expressions. Use Log activity as below in Java Script expressions to verify the same.




  • When Content-Type is application/xml, process.body is logged as below

[PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST] CreateEmployeeLog: <a>[[<b>1233333</b></a>]]

  • When Content-Type is application/json, process.body is logged as below

     [PostPipelinePair, request-ab047b9.N47e0f03.0.15591b0ca2c.N7d1d, Stage1, REQUEST]         CreateEmployeeLog: {"a":1234,"b":3455}

  • Though REST service supports JSON/XML payload, there is no automatic conversion takes place at runtime and to be done programmatically in native REST services.
  • When using End-to-End XML, use XQuery/XSLT for transformation.
  • When using End-to-End JSON, use Java script for transformation.



Enabling Logging in Service Bus

To enable pipeline logging in Service Bus, steps remain same as below but the location where do we do this activity changed. The screenshots shown in this post

  • Enable logging in Global Settings
  • Enable logging at Pipeline level

Global Settings

Login to EM Console and navigate to SOA –> service-bus (Admin Server) as shown below.


Click on Global Settings tab and set Logging Enabled property. We can also enable Monitoring, Alerts, Reporting and Result Cache as shown below.


Pipeline Settings

In EM Console, navigate to SOA –> service-bus –> <<Service Bus Project>>.


Go to Operations tab and query for Pipelines. Here we can see all monitoring related properties for Pipelines.


Click on Pipeline and go to Properties tab to enable Logging as shown below. We can set other Monitoring and Tracing related properties as well. We can also set log level so that it will be shown in log files.


This logging information is shown in <<osbservername>>-diagnostic.log.

Another related blog entry:

Service Bus 12.2.1 – REST Support

In this blog, we will review native REST service support added in 12.2.1. And you can refer to post to find information about same from 12.13 perspective.

Before discussing further, we will first see how 12.2.1 provides the backward compatibility with 12.1.3. In 12.1.3, REST Proxy Service converts native REST payload to SOAP before calling a Pipeline/Split-Join and REST Business Service convert SOAP to REST native payload i.e. the internal communication happen using WSDL interfaces only.

In 12.13, while creating REST binding as Proxy or Business service check the option as shown below and other steps remain same.

We can see WSDL and WADL gets created in your project.




To access REST resource use url like http://localhost:<<OSB Port>/<<proxy endpoint>>/<<resource name>>  so it will be http://localhost:7003/restDemo/REST1213WayPS/employees

To access design-time WADL use url like http://localhost:<<OSB Port>/sbresource?WADL/<>/<>  so it will be http://localhost:7003/sbresource?WADL/RESTIn1213way/WSDL/REST1213WayPS

To access effective WADL use url like http://localhost:<<OSB Port>/sbresource?(PROXY or BIZ)/<<project path>>/<<proxy or biz service name>>  so it will be http://localhost:7003/sbresource?PROXY/RESTIn1213way/ProxyServices/REST1213WayPS

Now in 12.2.1, we have native REST support and no need of creating WSDL for internal communication. This native support is broadly classified into following categories:

  • Un-typed Proxy/Business Service –  For which method information is available at design time so no WADL is involved.
  • Typed Proxy/Business Service – For which the method information is available at design time so WADL is used/created having this information.

REST binding can be used to create both Proxy and Business services that fall into above categories. In this post, we discuss from Proxy Service perspective and same can be followed for business services.

Creating Typed Proxy Service:

We use REST binding to create native REST service. So drag REST binding from Components to Proxy Services swim lane or right click to choose REST option.


Provide name for REST binding and do not select WSDL interfaces check box as we are creating native REST services. Click Next.


Create a new REST resource as shown below.



Create a REST method using following steps by clicking + icon in Methods.




Now verify that WADL file is generated automatically with method information as defined above. Now create pipeline using the following steps.





Connect Proxy Service, Pipeline and Business Service as shown below. Use the same business service as we used earlier.


Finish the message flow as shown below.



Deploy and test your project in Service Bus console. Observe that you can see all media types supported by REST service are shown in Accept choice list.



Now we will see how to use an existing WADL to create Typed REST services.

Again drag the REST binding from Components to Proxy Services swim lane or right click in swim lane to choose REST option.


Provide name for REST binding and do not select WSDL interfaces check box as we are creating native REST services. Click Next.


Choose REST1213WayPS.wadl. This confirms that WADLs generated by 1213 REST services are supported here. Observe that REST methods are populated automatically from selected WADL.




Click Finish and verify that new WADL is generated again for this Proxy Service.


Now finish pipeline message flow as above using WADL created in above step.



To access REST resource use url http://localhost:7003/restDemo/typedService/typedEmployees

To access design-time WADL use url http://localhost:7003/sbresource?WADL/RESTTypedServices/TypedRestService

To access effective WADL use url http://localhost:7003/sbresource?PROXY/RESTTypedServices/TypedRestService


  • WADL is always created for Typed native REST services when one is not chosen during creation.
  • No where we are able to give the input/output message structure (XML or JSON schema) for REST methods. I think this may be improved in later releases.
  • When a native REST Proxy Service supports multiple content types (XML, JSON), automatic payload conversion (XML to JSON and vice-versa) is not happening as we see in WSDL based REST services. I will try to cover more on this in later posts.
  • Content-Type HTTP header is used by OSB for content parsing and we can see this set automatically when media type is chosen in test console.
  • Value given for soa:name in WADL is populated for $operation context variable in pipeline.
  • 1213 WADL is not supported for creating pipelines but can be used to create Proxy, however a new WADL will be generated by OSB as we saw above.

Creating Un-typed Proxy Service:

Create a Proxy Service using following steps. Observe the usage of Transport and no where we define REST resource or methods.





Create pipeline using following steps and observe that we are not selecting any WADL as we did earlier.



Connect all these pieces as shown below and complete Message Flow as we did earlier.


Deploy and test your project in Service Bus console. Observe that you can see all media types supported by REST service are shown in Media Type choice list as we have not specified supported types any where. Service Bus uses the Content-Type HTTP header for parsing the payload and you can see this is set automatically when we choose the media type in Test Console.



To access REST resource use url http://localhost:7003/restDemo/untypedService


  • No WADL is used during creation of Un-typed native REST services.
  • Again, no where we are able to give the input/output message structure (XML or JSON schema) for REST methods.
  • Again, no automatic payload conversion will happen when REST Proxy supports multiple Content Types.
  • Content-Type HTTP header is used by OSB for content parsing and we can see this set automatically when media type is chosen in test console.

In above 2 sections, we created  both Proxy and Pipeline separately and we can observe that WADL is optional for REST based pipelines. So even Pipelines are classified into Typed and Un-typed  depending on usage of WADL.

So now the Q arises about compatibility between Proxy and Pipelines as both of them can be Typed /Un-Typed. Since Typed is more restrictive having REST methods we will be able to call both Un-Typed and Typed pipelines provided they used same WADL. In the same way, Un-Typed will be able to call both Un-typed and Typed Pipelines.

The source code used in this post can be downloaded from here and please note that you need to create DB connection pool to run this project with JNDI eis/DB/LocalDB.


FMW is released !!!

FMW was released last week and it seems to be a patch release for 12.2.1. Some quick links related to SOA are given below.






12.2.1 OSB JDev Issues

The following information is related to 12.2.1 release unless stated otherwise.

Issue 1:

OSB projects are being converted to SOA projects after adding a XQuery to workspace. You can confirm this by looking at components window which shows SOA related components after opening a pipeline.

Fortunately, this issue is already documented by in support note 2090174.1 and the solution is applying the patch 22226040. Refer to this post for instructions on applying the patch. Make sure that ORACLE_HOME and MW_HOME are pointing to right locations when you have multiple middleware homes.

Verify that patch is successfully applied by issuing opatch lspatches. Restart jdeveloper after clearing the cache (system directory).

If you still see this issue, verify the jpr files TechnologyScopeConfiguration does not have SOA entry similar to below.

<hash n=”oracle.ide.model.TechnologyScopeConfiguration”>
<list n=”technologyScope”>
<string v=”Maven”/>
<string v=”ServiceBusTechnology”/>
<string v=”WSDL”/>
<string v=”WSPolicy”/>
<string v=”XML”/>

Issue 2:

For the first time, jdeveloper is getting stuck saying ‘Loading Maven…’ when opening any existing Service Bus application. To resolve the issue, modify the version to 12.2.1-0-0 in parent section of pom files of service bus projects including System project. Sample is shown below.


SSL using KSS

In this post, we will use KSS (Keystore Service) for SSL setup. The screenshots showed in this post are based on SOA 12.2.1 but these steps remain same for 12.1.3 as well.

Creating Application Stripe:




Creating KSS Keystore:



Creating Keypair:




Oracle recommends key size to be more than equal to 1024. If we want to get it signed by any CA, we can generate CSR by clicking Generate CSR which is recommended for Production env. But for Development purpose we can use this keystore as it is.


Clicking on alias name will bring up the following screen showing the certificate information.


Configuring 1-Way SSL:

Enable SSL port by navigating to Environment –> Severs-> Admin Sever –> General.


Go to Keystores tab. Click Change to select Custom Identity and Custom  Trust as shown below and click Save to save the changes.


Modify Custom Identity and Trust stores as shown below. observe the usage of system trust store kss://system/trust. Oracle recommends this approach to simplify the trusted certificates setup.


Go to SSL tab and give the Private key alias as shown below. Here give the password as “password” and click Save. See related note at end of this post.


Go to Advanced settings and set Hostname verification to None and also set Two way Client Cert Behavior to Clients Certs not Required as we are doing setup for 1-way SSL. This setting will enforce WLS server not to request client certificates.


Restart the server and now we should be able to access admin console using HTTPS URL like http://localhost:7002/console.

Similarly, configure OSB managed server using same Keystore or by creating a new one similar to above as shown in the following screenshots.. Restart the server after changes.




Enable HTTPS for OSB proxy service as shown below.


And now we should be able to access the proxy service WSDL using HTTPS URL like https://localhost:7008/entity/CustomerService?wsdl

Refer to this post for 2-way SSL setup and follow below steps to import the certificate into trust store.





Note that KSS does not support certificate in binary format which is the default encoding used by JKS. We can use –rfc option of keytool command to export the certificate into printable encoding format as shown below.

keytool -export -keystore .\soakeystore.jks -file cert.cer -alias localsoa -rfc


When no Private Key Passphrase is mentioned in the SSL tab, em console is not accessible and following errors are shown in the log.



MAF 2.2 to MAF 2.3 observations

Continuing with previous article, the same MAF application has been migrated to 2.3 and here i want to highlight my observations. As usual, the list is not exhaustive and depends on the features that we used. For  more information on 2.3 release, refer to documentation here.

  • Now the default Alta Skin version is 1.5, however we need to manually modify to this version in maf-config.xml.
  • Since Windows 10 support is added, now migrated application will have windows related resources and deployment profile.
  • The plugin-ids for core plugins Contacts are changed to cordova-plugin-contacts.
  • Now maf-application.xml shows cordova engine versions supported by MAF for each platform (Android, iOS, Windows).
  • Login connection configuration does not have Mobile-Social as one of the mechanisms and users are advised to use oAuth2.
  • oracle/wss_http_token_over_ssl_client_policy is not listed in OWSM policies in Security section of maf-application.xml.
  • All allowed URL Schemes that are allowed to be accessed have to be listed in maf-application.xml -> security for iOS.
  • Whitelisting is removed from maf-application.xml and also the API AdfmfJavaUtilities.addWhiteListEntry(Entries) are deprecated.  Refer to this post for implementing this functionality manually.
  • Now the RestServiceAdapter to be initialized in the following manner and old class has been deprecated. Observe the imports below.


                             RestServiceAdapter restAdapter = RestServiceAdapterFactory.newFactory().createRestServiceAdapter();

  • setRequestType() method in RestServcieAdapter is modified to setRequestMethod().

I observed the following issues are resolved in MAF 2.2:

  • Fcaed some issues with plugman during the installation of cordova plugins (e.g.: Barcode scanner) in linux envs when used symbolics based Source control system. Basically, its an issue with symbolic links.

Using ADFBC REST Services in MAF

This article is presented in tutorial format and can be downloaded from here and sample application from here.

MAF 2.3.2 Released!!

Oracle Mobile Application Framework (MAF) version history is available here.

MAF 2.3.2

A few of the prominent features include IPV6 support in iOS (mandated by Apple since 1 June 2016), built-in federated authentication support and support for generating quick start page layouts for common mobile patterns.

Refer to this link for list of all new features in this release.

MAF 2.3.1

Refer to this link for list of all new features in this release.


This is a small release having fixes for some of the iOS deployment issues.

Refer to this link for list of fixes included in this release.

MAF 2.3

The prominent features included in this release are support for Windows and Enterprise Mobile Management (EMM). This version of MAF includes the support for Cordova 4.1.1 for Android platform and 4.0.1 for iOS platform . Starting from May 2-16, Google Play store blocks applications using Cordova version <4.1.1 so users should upgrade their applications to this release if it has to be uploaded to play store.

Refer to this link for list of all new features in this release.

MAF 2.2.2

There are no.of features deprecated in this release and refer to release notes below.

MAF 2.2.1

MAF introduced XCode 7 support but did not mention Android 6.0 (Marshmellow) in certification information. I was waiting for this update as i faced a few issues in 2.2 release as i mentioned here.

MAF 2.2

Oracle had released Mobile Application Framework (MAF) 2.2 last week and one of the awaiting releases. You can find the links below:

You can observe some of the features are deprecated in this release including Webservice Data Control for SOAP Services and recommends customers to use REST services with JSON.

MAF 2.1

You can find a nice tutorial on MAF here though not specific to this release.

Installing Cloud Adapters

When JDeveloper 12.1.3 is installed, the Sales force adapter is shown and available by default but the other cloud adapters like Sales Cloud, Right Now, HCM Cloud etc.. will not be available. In this post, I will show how to install these adapters through patches provided by Oracle.

These integration adapters can be downloaded from here and available on top of (BP1). Do download Oracle Cloud Adapters


  • Install Oracle SOA 12.1.3 using quick installer.
  • Apply p19707784 using OPatch  to bring it to BP1. Refer to this post for additional help on OPatch utility.
  • Unzip the above download and observe the following patches available.


  • Apply p20680367* and p20780464* in same middleware home.
  • Create JDeveloper shortcut from below location and open to observe the cloud adapters Eloqua Adapter, Oracle HCM Cloud, Oracle RightNow and Oracle Sales Cloud available in Cloud section. You will get to see this section when you create new SOA or Service Bus Application.


  • If you are not seeing these adapters, add –clean** option as shown below in your desktop shortcut and re-open JDeveloper.  

MW_HOME\jdeveloper\jdeveloper.exe -clean

* Always read the patch README files and follow the available instructions.

** I thank my colleague who helped me by providing this workaround.



Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 353 other followers

Enter your email address to follow this blog and receive notifications of new posts by email.