Skip navigation
ANNOUNCEMENT: is currently Read only due to planned upgrade until 29-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

Business Process Management (BPM) enables enterprises to rapidly adapt their business to reflect the constantly changing market conditions. BPM is now offered as a Platform as a Service (PaaS) offering, combining the benefits of application development and process support in an integrated cloud model.


Typically business processes constitute applications / systems from various LOBs, partners and external parties some of them on cloud and some on-premises. This requires a powerful integration platform to efficiently and easily integrate systems both on cloud and on-premises. Oracle Process Cloud service and Oracle Integration Cloud service are two PaaS offerings from Oracle which enables enterprises to rapidly design, manage business processes and integrations in the cloud.

In this post we will look at the steps involved in developing a simple business process (Funds Transfer Process) using Oracle Process Cloud Service (PCS) which calls an integration deployed in Oracle Integration Cloud Service (ICS) to communicate with an on-premise web service to complete the funds transfer process. The following diagram depicts a high level overview of how the Funds Transfer sample will be realized:


Figure 1: Overview of Funds Transfer Sample

Note: Although this post attempts to explain all the key steps involved in building this sample, it does not delve into the security aspects.

The following flow chart represents the business process that we will be building, “Call Funds Transfer Service” in the below diagram represents a SOAP based invocation of ICS integration:


Figure 2: Funds Transfer Flow Chart

The final state of Funds Transfer business process we will look as follows:


  Figure 3: Funds Transfer Business process (final state)

The content of this post is segregated into three parts:

  • The first part discusses about business processes in PCS, REST connector and Human task configurations.
  • The second part would focus on developing integration flow in Oracle Integration Cloud service (ICS) and creating connectors for on premise web service integration.
  • The third part will bring all these capabilities together to realize the Funds Transfer business process.

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

This is the final part of the blog post - "Business Process Orchestration and Integration in Cloud using Oracle PaaS" emphasizing on the high level steps to invoke the ICS integration from the business process via SOAP connector, deploying, executing and tracking the business process instances. While the Part-1 discussed about business processes in PCS, REST connector and Human task configurations, the Part-2 detailed about developing integration flow in Oracle Integration Cloud service (ICS) and creating/configuring connectors for on-premise web services.


Create and configure SOAP connector

As depicted in Figure: 3, the activity “Call ICS” is a service call to an ICS integration exposed as a SOAP endpoint. PCS provides a “SOAP connector” that can be configured to call a SOAP service. The following diagrams show how to create and configure a SOAP connector.

Click on the “Connectors” link on the left panel and select “New Web Service Connector” as shown below:


Figure 41: Add Service Connector

In the “Add service connector” wizard that opens up, select “Upload from File” option, choose the WSDL file of ICS integration (downloaded as specified in Figure: 40 of Part-2). Specify the name for the connector and also configure the security attributes as shown below:

Note: For the process in PCS to be able to invoke the ICS integration, it should be authenticated. This example uses App Id- Basic Auth security policy. This username/password pair is stored in a Credential store configured under Administration page in PCS console as shown in Figure: 43


   Figure 42: Configure SOAP connector

Manage Credentials

Navigate to the PCS home page and select “Configure” icon to create a new credential store. Click on “Add new Credential” as shown in the following diagram, specify the key name and provide the username and password. These credentials can be used when configuring the connection’s security by mentioning the key name.


Figure 43: Manage Credentials

Implement “Call ICS” activity of Funds Transfer process

Now that the SOAP connector has been successfully configured to connect to the ICS integration, use this SOAP connection for implementing the “Call ICS” activity in the Funds Transfer business process as shown below:


    Figure 44: Configure ICS service call in business process

Define the input and output data mapping of the “Call ICS” activity as shown in the below two diagrams:


    Figure 45: Request data mapping                                                                                                                                                                          Figure 46: Response data mapping

Note: For simplicity, the on premise web service has been implemented such that it returns a “Success” response if all the request attributes have non null values.

This step completes the implementation of the funds transfer business process which should like below:


   Figure 47: Final state funds transfer business process

Deploy the business process

The application can be validated for any anomalies by clicking on the  button as depicted on the right top of the above diagram. Once the process is validated it can be deployed. Click on the “Management” link on the top as depicted in the previous diagram, in the next page, click on “Deploy” link appearing on the left top, “Deploy Application to My Server” wizard opens up. Deploy the application following the below diagrams:


Figure 48: Deploy business process

Once the business process is successfully deployed, you can retrieve the WSDL of the deployed business process as below:


   Figure 49: Funds Transfer business process exposed as web service

When “Web services” menu option is selected as shown above, the “Manage Web Services” page opens up showing all the business processes contained in the deployed application as shown below. This WSDL can be used to trigger the Funds Transfer business process as a web service by passing the data as specified in the “Start” activity. The created process instances can be tracked by clicking on the “Track Instances” icon as shown below:


Figure 50: PCS Home page

The following diagram shows a successfully executed Funds Transfer business process going through the manual approval.


    Figure 51: Track business process instances

Conclusion: This completes the blog post - "Business Process Orchestration and Integration in Cloud with Oracle PaaS". In this post, we have seen how Oracle PCS and ICS offerings put together eases the development of effective and standard driven business process orchestrations and integrations in Cloud.

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

This is the Part-2 of the blog post - "Business Process Orchestration and Integration in Cloud using Oracle PaaS" emphasizing on the ICS aspects like creating and configuring integration and SOAP connector to invoke an on-premise web service for completing the funds transfer process. The Funds Transfer business process uses ICS for connecting to an on-premise web service to complete the process execution, please refer to Part-1 for business process orchestration and related configurations.


When you log into the ICS server, you will see the following landing page from where you can create connections and integrations. To create a new integration you would first need to create a connection that can used in the integration.


   Figure 23: ICS Home page

Click on the “Integrations” icon, you will see the Integrations page displaying the existing integrations (if any) as below:


   Figure 24: Existing Integrations

Create an agent group

The Funds Transfer business process involves invoking an on-premise web service via ICS integration to complete the transfer process. Connectivity to on-premise in ICS is established using an “Agent”, click on the “Agents” link on the left panel which opens the Agents page displaying the existing agent groups as shown below:

Note: You have to download and install the ICS connectivity agent which is the bridge to connect ICS to on-premise services. Details about downloading, installing/configuring the ICS agent is beyond the scope of this post, please find more details here.


   Figure 25: Create Agent Group

Click on “Create a new Agent Group” button on the right side for creating a new agent group which would be used to invoke an on-premise web service. Name the agent group as “ICS_OnPrem_AG”, this name would be specified when configuring the connection.


   Figure 26: New Agent Group Information

Create Connections

Click on the “Connections” icon to see the Connections page, click on “Create Connection” button on the right side for creating a connection as shown below to connect to the on-premise SOAP service:


   Figure 27: Create Connection - Select Adapter

Select “SOAP” from the list of adapters shown and provide new connection details as shown below:


   Figure 28: New Connection Information


Configure the connection attributes as shown below; this connection uses a SOAP adapter to connect to an on-premise web service via the agent group (ICS_OnPrem_AG) which was created earlier.

Note:  This example assumes that there is a web service deployed and running on an on-premise Weblogic server, the WSDL of this web service is specified while configuring the SOAP adapter.


  Figure 29: Configuring SOAP connection for on premise service invocation

Click “Configure Connectivity” button to specify the WSDL details of the on premise service as follows:


   Figure 30: Configure Connectivity

Before you can use the connection in an integration flow, ensure that the connection is tested and the state of the connection is shown as 100% as shown below (on the extreme right):


  Figure 31: Ready to use Connection

Create a connection (FTS_Source) for configuring the source endpoint as follows:


  Figure 32: Create connection for integration source

Note: The ICS integration will be invoked as a SOAP service hence the source node of the integration (please refer to Figure: 34) is configured with a connection that uses SOAP adapter. The WSDL file uploaded here will be used for initiating the integration from outside ICS. Please refer to ICS documentation for more details.

Create an Integration Flow

Now we have the on-premise connection and source connection ready, create an integration using these connection definitions by selecting “Basic Map Data” pattern as shown below:


   Figure 33: Create new Integration

The Integration flow canvas opens up with source and target nodes; there is a palette on the right side which lists all the defined connections. Locate the connection from the palette that you have created for connecting to the on-premise web service (FTS_ON_PREM) and drag/ drop the connection onto the target node as shown below:


   Figure 34: Drag and Drop connection onto target node

You will see a “Configure SOAP endpoint” page as shown below, give a name to this endpoint and click “Next”. The summary tab (shown below) displays the details of the web service and the operation being invoked using this endpoint configuration.


   Figure 35: Configure SOAP endpoint

Locate the connection from the palette that you have created for source connection (FTS_Source) and drag/ drop the connection onto the source node.After configuring the source and target nodes of the integration it should look like below:


   Figure 36: Integration with configured source and target connections

Map Request and Response

Click on the “Click Below to create Map” link (shown in the above diagram) to add data transformers to the request and response paths as shown below:


   Figure 37: Map Request and Response data

After completing the above steps successfully, your integration should look like below:


   Figure 38: Integration after configuring data transformations

Exit the Integration by clicking on the “Exit Integration” button on left top and activate the integration by clicking on the “Activate” button as shown below:


     Figure 39: Activate Integration

After the integration is activated, by placing the mouse cursor on the information icon (as shown below) you will be able to find the endpoint URL of the ICS integration that you have built. You can use this endpoint URL just like any other WSDL endpoint to invoke the integration as a web service.


Figure 40: WSDL for Integration

This concludes the Part-2 of this blog post, please refer to Part-3 where all these pieces will be brought together for invoking the ICS integration defined above from the PCS business process defined in Part-1.

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

This is the Part-1 of the blog post - "Business Process Orchestration and Integration in Cloud with Oracle PaaS". Oracle PCS is a BMPM 2.0 compliant BPM offering on cloud (please refer to for more details on BPMN standard). The highlighted BPMN constructs of Oracle Process Cloud service (PCS) are used to build the Funds Transfer business process:


Figure 4: BPMN Palette

Create a business process

From the PCS console, select the “Develop Processes” option to define the Funds Transfer business process as depicted below:


Figure 5 : Develop Processes

The “All Spaces” page opens up displaying the existing applications (if any) as follows:


Figure 6 : Landing page showing the existing applications

In case you want to create a new application or a new space, you can do that by clicking on the “Create” button as shown below:


Figure 7: Create new Space/Application

Business processes are created in an application which in-turn resides in a space. In this case we create the Funds Transfer process in an application called “My Application”.  Once you select the application, you will see the “Application Home” page displaying any existing business processes (if any) as shown below:


Figure 8: Page displaying existing business processes

As you can see, on the left menu in the above diagram, you will find various options like processes, web forms, types…etc. You can click on each of these links to get into the details.


Create a Business Process

Click on the “+” icon on the extreme right to create a new business process, a “Create Process” page opens up where you can give the details of the business process and select a pattern based on which you will be building the process.

As we want this business process to be triggered from an external application like a UI or from an external service we use “Message” pattern which kicks off the business process upon receiving a message.


Figure 9: Create Process Page


An empty business process is created with start and end events and is opened in a canvas as shown below.


Figure 10: New process with start and end activities

Drag and drop the respective activities/tasks from the BPM palette onto the canvas and wire them appropriately so that your business process should like figure 2. For more details on how to do this, please refer to the PCS documentation.

Once the skeleton of the process is ready you can configure/ implement the activities which would require defining business types, creating connectors to make service calls and configuring human tasks that are needed to realize the Funds Transfer business process.

Define Business Types

Business types are complex data structures that are used as containers to send data from one component to the other. The following diagram depicts the business objects being used in the Funds Transfer process:


Figure 11: Page displaying the existing business type definitions


The following image shows the attributes of each of the business types. The “FundsTransferDataForm” business type is used to populate the form which is used to display the request data to a human for the manual approval activity. The “ResponseFromValidator” type is used to capture the response sent by the REST service after validating the request. The “FundsTarnsferBO” type is used for sending the request to the on-premise web service call to perform the funds transfer. More details about the REST / on-premise web services and their respective configurations can be found in subsequent sections.


Figure 12: Business Type attributes

Configure the “Start” activity

You can configure/implement the ‘start’ activity of the business process by clicking on the “Start” activity and then clicking on the details  icon as shown below:


Figure 13: Configure Start Activity


As you can see above, we have defined an interface with five attributes and associated it with the “Start” activity, these five attributes constitute the request for the business process.

Note: Once the Funds Transfer process is deployed to PCS runtime, a WSDL endpoint is generated for this business process enabling it to be invoked as any other web service. More details about this will be provided later in the post.

Create and configure REST connector

As depicted in Figure: 2, the next activity is “Validate req” which is a service call to a REST endpoint that is deployed in Java Cloud Service (JCS). PCS provides a “REST connector” that can be configured to call a REST service. This example assumes that there is a REST web service deployed and running on JCS, the details of the REST endpoint are specified when configuring the REST connector. The following diagrams show how to create and configure this:

Note: In this example, APP Id – Basic Authentication security policy is used for authentication. You can define a new key (the diagram below shows a key created with name “JCS-SX”) and specify the username and password used for connecting to the REST service.

REST_Connector_1.png    REST_Connector_2.pngREST_Connector_Config.png

Figure 14: Create REST connector                                                                                                                                                                                                                                                                    Figure 15: Configure REST connector

As you can see in the above configuration, the request received by the Funds Transfer business process is validated by invoking a REST service deployed in JCS.


Note: To keep things simple, the REST service just takes the “incidentId” attribute from the request as input and returns a failure if it is NULL which means the request is invalid.


Once the REST connector is configured it can be used to define the “Validate req” activity (which is a service call) of the Funds Transfer process as shown below:


Figure 16: Implement service call activity using REST connector

Select the “Type” as ‘Service Call’ and select the REST connector that you have created in the previous step and choose the resource and the operation you want to call on the selected resource for validating the funds transfer request.

After the implementation details have been provided, you need to map the input to and output from the REST service as shown in the below diagrams. Also note that the business types defined above are being used when mapping the request/response.


Figure 17: Request and Response data mapping to REST service

Please refer to the Oracle PCS documentation for more information on working with REST and Web Service connectors.

Note: This post will not go into the details of implementing the “Exclusive Gateway” gateway.pngactivity which is similar to an if-then-else implementation. Please refer to PCS documentation for more details regarding this.

Create and configure Human task

The next important activity in the Funds Transfer process is the manual approval activity which needs human intervention to either approve or reject the funds transfer requests based on certain criteria. Configure the manual approval activity as depicted in the following diagram:


Figure 18: Configure Human task for manual approval activity


Select the “FundsTransferDataForm” as the web form to be used for presenting the request data to the reviewer. Specify “APPROVE” and “REJECT” as the two possible actions the approver can perform on the funds transfer request.

Note: The application users have to be mapped to roles (process owner and reviewer) so that they receive notifications and can act on the tasks assigned to them. Please refer to PCS documentation for more details.

If a funds transfer request needs a manual approval (transfer type = “inter bank”, amount > 10000) an email will be sent to the reviewer (needs to be configured as an Administration task) which looks like below:


Figure 19: Email notifications sent to reviewer

Note the link to the “Workspace Application”, when the reviewer clicks this link he/she is taken to the workspace where he can view the request details and act accordingly, the following diagram depicts this:


Figure 20: Request data being presented to the reviewer in a form

In order to receive email notifications, you have to configure the notifications by accessing the settings option as shown below:


Figure 21: Configure Administrative Settings                                                                                                                        Figure 22: Configure Email Notifications

Note: Please refer to Configuring Email Notifications in PCS documentation for more details.

Please refer to Part-2 of this post for creating and configuring integration and SOAP connector in ICS to invoke an on-premise web service for completing the funds transfer process

The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

The first part of this blog covered aspects that are important for developers to understand in order to build bespoke mobile applications that expose functionality empowered by Oracle eBusiness Suite (EBS). This blog builds on the information provided in Part I and deals with some of the implementation details



Implementation details




The content of this post primarily deals with details around the following components


  • Oracle Mobile Cloud Service: mobile backend, custom API and connector configuration
  • Oracle Integration Cloud Service: DB adapter, REST connection, mapping, agent configuration etc.


Please note that, for the ICS related aspects of the solution, a lot of technical details have been explained already in other blogs, thanks to the Oracle A-team



Therefore, this blog will not repeat those details but briefly touch base on the ICS part in order to capture comprehensive details of the solution.


Create Mobile Backend in Oracle MCS


The first and foremost step is to create a Mobile Backend for our integration. It serves as a way to group APIs and other resources for a set of mobile apps. A mobile application can only access MCS APIs in the context of a mobile back-end. By and large, a mobile back-end encapsulates the following


  • Connectivity information
  • Security related configuration: HTTP Basic, OAuth, Enterprise SSO etc.
  • Security Realm configuration
  • Mobile Application registration information and more..




                                                                 MCS Mobile Backend



For a step-by-step guide on how to work with Mobile Backend, please refer to the following section from the official product documentation


Custom API Design


Next, we will design the interface/contract of the API which will be exposed to the mobile clients. This will involve creation of the necessary REST endpoints along with the actions (HTTP verbs like GET, POST etc.) and required parameters (query, path etc.)




The above diagram depicts two endpoints – one which deals with risk orders and the other deals with unpaid invoices




This figure above lists the details of the GET operation on the riskOrders endpoint – it consists of a set of mandatory query parameters which need to be passed along with the HTTP GET request. Oracle MCS gives you the capability to design your Custom APIs from scratch using its declarative UI interface. For a deep dive of this process, please refer ‘Creating a Complete Custom API’ section from the product documentation


Data Integration


The following sequences of diagrams provide an overview of the stored procedures which contain the business logic to work with data in EBS


















Test the stored procedure as follows




You should get results like these




The below set of screens showcase the ICS EBS DB adapter configuration which includes both ICS agent and EBS connectivity configurations


ICS Agent Group





The following section from the product documentation covers the ICS Agent installation process


ICS DB Adapter







ICS (inbound) REST Endpoint


The ICS REST endpoint is a gateway for external callers (e.g. Oracle MCS REST Connector API) to invoke business logic associated with EBS integration. The following screens depict the associated configuration




























Once the REST endpoint configuration is complete, one can test the associated operations. Here is an example of GET operation which fetches sales orders from EBS for a specific customer e.g. Technologies








Oracle MCS: Connector API Configuration


The REST Connector API in MCS acts as a client for the inbound ICS REST endpoint (whose configuration was outlined above). The Connector API greatly aids in declarative security and testing.





The Remote URL highlighted in the above figure is the URL of the ICS REST endpoint. For details on Connector API configuration in MCS, please refer their respective sections in the product documentation – REST, ICS, SOAP


Oracle MCS: Custom API Implementation


The custom API implementation


  • Uses custom Node.js code to implement the contract/interface sketched out initially
  • It internally calls the MCS REST Connector APIs (for ICS)





This snippet demonstrates a HTTP GET operation on the riskOrders endpoint. It takes care of the following

  • Build Basic authorization token (base-64 encoded)
  • Execution of business logic by making a secured call to the Connector API


Please note how the Connector API is invoked


  • the constant (represented by ‘ICS4EBSConnectorBaseURI’ is nothing but the base URI exposed by the MCS REST Connector API i.e. /mobile/custom/AccountHealthEbsAPI
  • the remaining URI (highlighted) is the one which we defined during ICS (Inbound) REST endpoint configuration








Mobile UI Development


As mentioned in the Key Integration Components section of part I of this blog, one choose from a number of supported client frameworks in order to build the mobile application. This mostly involves leveraging the REST APIs exposed by the mobile back end. If we consider the example of a hybrid mobile application, here is the  Javascript jQuery Ajax call  for invoking a GET request


var settings =
            "async": true,
            "url": "https://my-mcs-instance:443/mobile/custom/AccountHealthEbsAPI/riskOrders?customer=your_customer_name&username=your_user_name&password=your_password",
            "method": "GET",
            "headers": {
                "oracle-mobile-backend-id": "oracle_mcs_backend_id",
                "authorization": "Basic eW91cl91c2VyX25hbWU6eW91cl9wYXNzd29yZA==",
                "cache-control": "no-cache"

$.ajax(settings).done(function (response) {

MCS Platform Aspects


It is rather tough to cover all the feature of Oracle MCS is a couple of blogs. The important thing to note is that, MCS provides a comprehensive mobile back end platform which includes support for features such as Push Notifications, Analytics, Storage, offline data and sync etc. These can be best explored using Platform APIs section in the official product documentation




This blog does not cover the relevant security aspects from code & implementation perspective, but the below mentioned items are worth exploring from a deep dive perspective


  • Authentication: identifying valid mobile users using options ranging from HTTP Basic Auth, OAuth, Enterprise SSO as well as social login (Facebook is supported at the time of writing)
  • Authorization: protecting Custom APIs based on roles configured within MCS
  • Outbound Security: Connector APIs leverage declarative security policies to connect to external services
  • Identity Propagation: this involves transmission of the authenticated user context from the mobile app right down to the external system (using Connector APIs) based on tokens/assertions (without exchanging sensitive user credentials)


With this, we have reached the end of this two-part blog series !


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

This blog covers topics which are important to understand in order to build bespoke mobile applications which expose functionality powered by Oracle eBusiness Suite (EBS). Teams can leverage the information presented in this blog for multiple aspect of their mobility projects, including planning, design and development



Current offerings & potential opportunities


EBS has a considerable number of mobile apps available as part of the product stack. Also, Oracle Mobile Cloud Service (MCS) latest offerings contain few mobile apps that have been released for EBS Self service and expense management features . However, as a developer working for an enterprise IT having EBS deployed, you still may need to build custom mobile apps that would need to expose business critical data, fetched from EBS, to end users. This could be a mobile app which exposes valuable information congregated from disparate cloud and on-premises applications on a single and intuitive interface, and is therefore completely isolated from other EBS Mobile apps available out of the box.

As an example, consider a fictitious company VISION CORP that sells computing hardware and data center equipment. They used to manage customer experience focused aspects using On-premises deployed Oracle Apps, but have now invested in Sales Cloud, for managing deals and opportunities, and also service cloud for customer service requests. They still use on-premises EBS for tracking Sales orders and invoices. Vision tracks customer data in several systems and to pull together the right information at the right time is quite challenging. Some of the existing customers may be new opportunities too based on their potential need to purchase new products and services. Therefore Vision IT department need to build an “Account Health” Mobile app for sales reps that aggregates customer information into a single, easy to use interface available from any smart phone. This single app should fetch data from Sales Cloud, Service Cloud and on-premises EBS, as shown in the figure below. Sales reps should now be able to quickly review and act on the critical account health information, before meeting existing customers (who are also prospective opportunities for additional sales) in order to successfully conclude relevant deals.


Mobile Application fetching data from Oracle Sales Cloud, Service Cloud and on-premises EBS.JPG


                             Mobile Application fetching data from Oracle Sales Cloud, Service Cloud and on-premises EBS


Selecting the right Cloud Platform for your Mobile Backend


A comprehensive Mobile Backend is the foundation for a successful mobile app development practice. A wise approach would be to leverage the compelling features which Oracle Mobile Cloud Service (MCS) gives you right out of the box




                                                            Oracle MCS: high level architecture


These include


  • Platform to host back-end APIs and implementations
  • Support for mobile platform aspects – Security, Storage, Offline Data synchronization, Device Notifications, Location Services and Analytics.
  • Easy interfaces for no-code UI development and SDKs for diverse set of UI development frameworks
  • Quick & secure Integration with back-end systems, using connectors


It’s important to note that all of this is available without you having the need to install/configure and thereafter monitoring/patching/upgrading mobile back-end software infrastructure in your data centers.




Reference architecture presented below can be used for building bespoke mobile apps exposing data from on-premises EBS. It’s the same architecture also covered in the other blog from Oracle A-team.




                                                            Architecture for Mobile App fetching data from on-premises EBS


Key integration components


Client Side


The client side is nothing but the mobile application. It needs to fetch relevant information from on-premises EBS e.g. information related to sales orders and invoices. It could be developed using any client technology which MCS supports


  • Native client SDKs: Android, iOS, Windows
  • Hybrid clients SDK: Apache Cordova
  • JavaScript SDK: for use with browser based apps and hybrid frameworks (other than Cordova)
  • Support for Xamarin and Swift: you can also use the MCS SDK with Swift applications and Xamarin platform also provides and SDK which you can use with MCS


You can refer the official documentation (Part II) for a detailed insight into all of the SDKs mentioned above.


In addition to existing SDKs, you can also use the following


  • Oracle Javascript Extension Toolkit (JET): from the context of the use case presented in this blog, JET (which is Javascript development toolkit) can serve as a suitable platform for hybrid application development
  • Oracle Mobile Application Framework (MAF): It is a comprehensive mobile application development platform using which you can build applications and deploy to iOS, Android and Windows platforms, all using a single code base. MAF is ideal for building mobile applications on top of backends built with Oracle MCS since it can leverage the REST APIs which MCS exposes


Target Systems


Oracle EBS serves as our target system in this case. It is the repository of information on top of which integrations are built in order to work with the data it contains. Data can be collected from EBS by setting up Integrated SOA Gateway and accessing the SOAP/REST interfaces. Relevant details are mentioned in My Oracle Support documents for EBS version 12.2.x (Document ID 1311068.1) or 12.1.x (Document ID 1998019.1). Considering this integration approach, Oracle Integration Cloud Service (ICS) EBS Adapter can be used to further build integrations. If EBS version is 11.x, the provision to setup Integrated SOA Gateway is not available and therefore the data will have to be collected by directly accessing EBS database and invoking PL/SQL APIs. Considering this integration approach, ICS Database Adapter can be used to further build integration in ICS




Oracle Mobile Cloud Service


MCS would be used to model the mobile backend for integration with the mobile application. MCS REST connector will be configured to connect with ICS integration source REST endpoint and get the data fetched from EBS. MCS Custom API implementation (Node.js code) will invoke the MCS REST connector to gather EBS data, and will expose a REST endpoint for the Mobile app client to invoke.


Oracle Integration Cloud Service 


ICS is feature-abundant, but, from the context of this post, the following capabilities are critical

  • Inbound REST adapter (source)
  • Outbound DB adapter
  • On-premise agent


It will provide a suitable platform for integrating with EBS and exposing the fetched data to Oracle Cloud Services (like MCS) in a desirable format. The usage of ICS gains more relevance when EBS is behind corporate firewall. Enterprises do not want to open firewall ports to have Cloud services directly invoke EBS integration interfaces (even http enabled). The solution to this problem lies in an ‘agent’ based approach and is achieved through a combination of an on-premise ICS Agent and Oracle Messaging Cloud Service.


ICS On-Premises Agent


ICS On-Premises Agent would be used as a communication channel between EBS and ICS. The key point to remember is that you’re not obliged to allow incoming requests from Oracle cloud to on-premises EBS – thanks to the combination of ICS and Oracle Messaging Cloud Service


Oracle Messaging Cloud Service


It would act as a mediator between the ICS On-Premises agent and ICS on Oracle Cloud. The ICS agent will be reading messages and publishing to messaging infrastructure powered by Oracle Messaging Cloud Service. Integration should be built in ICS with target using EBS or DB adapter and source as REST. This would let ICS fetch data from EBS and expose it via REST endpoints.


Here is the sequence of events which takes place when the mobile application interacts with the server side integration[AG1]


  • The hybrid mobile app makes a call to the REST API exposed by the Custom API layer within Oracle MCS
  • The Custom API implementation internally invokes the ICS Connector API (configured in MCS)
  • The ICS REST endpoint is called by virtue of the ICS Connector API integration
  • Now, the control flow passes on to the EBS DB adapter integration within ICS, which internally translates the (request) as a message and puts into the Oracle Messaging Cloud Service queue.
  • The ICS on-premise agent picks up the message from the queue and processes it – this results in the invocation of EBS
  • The results obtained from EBS are put into a Oracle Messaging Cloud service by the ICS on-premise agent and this is picked up by ICS component running in Oracle Public Cloud
  • The call chain now reverses i.e. the response is passed back to the Connector API, from where it reaches the Custom API and finally back to the mobile client


Mobile App Development Approach


Using Oracle Mobility platform, following approach is recommended for building mobile apps. Though most of these considerations are applicable as general best practices, there are a few specific ones related to integrating the mobile implementation with on-premises EBS


Building the Core Functionality


Based on the requirements of the mobile app and the exact information required from the back end systems (EBS, in the current context), the actual core functionality of the solution is most important. It means - what is the purpose of the app, who are the user actors who would use it, what are the exact screens are required, what should be displayed on those screens, where will that data be obtained from.


Leveraging Platform Aspects


Once the core functionality is fathomed, additional relevant aspects that are more sort of mobility platform aspects need to be also devised - like Security, Offline synchronization/caching of relevant data etc., Storage of mobile content on Cloud (not on device), sending device Notifications, introducing Analytics. Implementation of these aspects would have impact on how developers would build various tiers of the overall solution – UI, mobile service, integration, EBS specific data collection.

Development Strategy

Having considered these aspects and based on the architecture presented in the previous section, Fig 3 shows a project planning approach for various tasks involved. It is apparent here that using Oracle cloud platform and recommendations, enterprises could rapidly build EBS Mobility solutions by having different developer personas executing in parallel without any tight dependency on each other. For building a mobile app to fetch data from on-premises EBS, using Oracle Cloud Platform, the bare minimum skill based personas required in the team should comprise of

  • Mobile Developer: Creates Custom API endpoints and the UI which will invoke it. Also owns the major work on implementing the mobility platform aspects (security, notification etc.). Also work on configuring secure mobile app access, may be with the help of security/Identity and Access Management (IAM) expert. Depending on the amount of work items involved and the level of segregation, one or more mobile developers could work in parallel, like one expert in Hybrid App development (using JET) building UI focusing on Look-and-feel (LAF) and the other one building custom API end points and configurations for push Notifications, Storage collections, Offline synchronization and so forth.
  • Service Developer: Creates the backend service implementation invoked by the MCS custom API, which includes MCS connector configuration and API implementation code developed in Node.js. Also would configure identity propagation to backend system, may be with the help of IAM expert.
  • Integration Developer: Creates ICS connections with required systems (like EBS) and actual Integrations including data flow with attribute mappings and transformations.
  • EBS SME (Subject Matter Expert): As an expert of EBS, analyzes available EBS APIs or the (database) data model to devise the data extraction logic.


In addition to the personas listed above, please take into consideration, some of the other relevant roles prevalent in a traditional IT project. These are Enterprise Architect, Program/Release Manager, Project Manager and IAM expert.





                                                                           MCS application development personas



In the initial phase of the project, diligent Requirement Analysis should be carried out. It should lead to the development of an exact UI Prototype of the mobile app, covering the details of each screen and the overall flow. Once the UI prototype is ready, it would be known - what exact information is required from EBS and what should be design/structure of actual MCS custom API which the app should invoke to render relevant information on UI.


Therefore the following two activities can be executed in parallel:


  • EBS Integration Analysis: Based on EBS versions and multiple other factors (refer Architecture section), EBS SME would have finalized on the EBS integration approach – Integrated SOA Gateway for Web Services based integration approach or direct database access. Based on the UI prototype details, if the information required from EBS is not available thru the OOTB APIs, then the EBS SME would have to develop and deploy EBS custom integration interfaces for gathering required data (as described here) or develop custom stored procedures and deploy them to EBS DB schema. These activities are a part of EBS Integration Configuration.
  • MCS Custom API definition: Based on UI requirements and the information required, it would be clear which screen default view, which swipe, which button click should render what data, and hence what should be the input and output expected from each of the corresponding MCS custom API invocations. Therefore, mobile developer can move forward defining the custom API skeleton and all the corresponding REST endpoints.


With the REST endpoints concluded with the MCS custom API design, Mobile Developer can go ahead and build the entire UI using the relevant client technology, without any dependency on another development activity in the project.Once the EBS Integration ready, mostly the Integration Developer (if having access to on-premises systems) or even the EBS SME can carry out the ICS Agent installation, directly on the EBS or another machine having proper connectivity with EBS. Thereafter, Integration Developer would proceed with ICS Integration Development. It will include creation of ICS connections and actual integrations - EBS as target and REST as source, with attribute mappings for request and response data flows. ICS has adapters for leveraging both approaches for EBS integration– Web Services based, using Integrated SOA Gateway (for EBS R12 onwards) or direct Database access invoking stored procedures.

With ICS integration available to fetch data from EBS, using the corresponding REST end point, it can be invoked by MCS using the MCS REST connector configuration. In addition to making this configuration in MCS, service developer would eventually develop the Custom API implementation, building the logic in Node.js, to invoke the corresponding MCS REST connector. With all the pieces finally ready, Integration testing of the end-to-end flow can be carried out to deliver a quality app


Based on the development strategy mentioned in this post, the implementation details have been covered in second part of this blog.


The views expressed in this post are my own and do not necessarily reflect the views of Oracle.

Oracle Internet of Things Cloud Service collect data stream from connected device and enable business users with wealth of information at real time to take key strategic decisions. To further maximize the value of bytes collected from remote devices, device data can be filtered, processed and merged with other existing and available enterprise information, analyzed and presented as useful reports to help business users.


As database acts as repository for any enterprise’s information, following presents primary motivators for integration between IOTCS and Database Cloud Service –

  1. Moving device data from IOTCS to DBCS for historical data analysis.
  2. Enable enterprise applications to enrich existing enterprise data and features by leveraging device data.
  3. Maximize the value of data from IOTCS by analyzing it with existing enterprise data.


Although this pattern can be applied and implemented to solve multiple business scenarios, few are listed below –


1. Surveillance Device Monitoring in Smart City – Alerts are generated when malfunctioning in the camera installed in various part of the city is detected. IOTCS capture this data, filter them to find valuable events, enriches them with the location of the device and stream it out to enterprise database. Enterprise application uses the device data with other enterprise data to analyze and display various metrics like how many time in last year this camera went off, what is the make and model of this camera, technician who repaired it last and when, maintenance and operational cost etc.


2. Fleet Monitoring and Alert Management for School Vehicle - Location Monitoring device installed in the vehicle send location data to IOTCS which will send it to enterprise database used by school management application. On receiving the data, enterprise application identity students who will be picked-up/dropped at the next stop and send their parent a mobile alert. Location data from IOTCS in enterprise database can also act as location archive for proof of historical events like child arrive at school on date D at time T.


3. Manufacturing device Monitoring – IOTCS will collect data from manufacturing device, filter/clean data for relevant information and enrich them with other contextual information before sending it to enterprise assets database. Enterprise application uses the device data with other assets information to present metrics like how old is the device, comparison with benchmarks, availability of similar device, supplier information, automated ordering of new device etc.

4. Smart Home Solution – Smart Container sends alert for refill to IOTCS to be streamed out to customer database holding customer settings for the smart container. Enterprise application combine data received from IOTCS and existing data in the database to identity commodity associated, customer preference for order, vendor information to which order is places etc and places a order automatically.


Technical Architecture



Key Cloud Services Involved


  1. Internet of Things Cloud Services – Oracle’s platform for Internet of Things offered as cloud services, connect, collect, analyze and forward device data.
  2. Java Cloud Service – SAAS Extension – J2EE container in Oracle Cloud used to host J2EE applications.
  3. Database Cloud Services – Database in Oracle Cloud to save enterprise data.


Key components


  1. Devices – Physical devices with sensors collecting specific attributes and sending them to Oracle’s Internet of Things Cloud Services.
  2. IOT Cloud Service – IOTCS will collect, filter and forward data to enterprise application.
  3. Enterprise Application – Deployed on JCS-SX, enterprise application expose rest-endpoint which will be used by IOTCS to push data to this application for processing. It processes and saves data to the enterprise database. Enterprise Application can use the saved device data for multiple modules like historical reporting and analysis.
  4. Database Cloud Service – Act as enterprise database.


System Interactions

  1. Device sends data to IOT Cloud Service.
  2. IOT Cloud Service capture the stream of data, filter/clean the data, enrich the data with contextual information made available at device registration and pushes data to REST Endpoint deployed on JCS-SX.
  3. REST Endpoint process the data and call DBCS REST Endpoint to store data along with other enterprise data into the Database Cloud service.
  4. Enterprise Application deployed in JCS-SX fetches data from DBCS to create various metrics and reports for business users



Oracle’s Internet of Things Cloud Service provides integration options that can be leveraged to maximize the value of your device data and to provide useful insight of your IOT deployment.

To know more about Oracle Internet of Things Cloud Service, visit


** The views expressed in this post are my own and do not necessarily reflect the views of Oracle. ** 



Smart devices continuously sending data every second to your Internet of Things Infrastructure and you are as a business user not able to find out any useful insight from this enormous amount of data. Are you also trapped in this?

Internet of Things is in vogue these days but just capturing the data is not enough if your IOT Infrastructure does not enable you to analyze the data and take business decision. To enable business user act rationally, lot needs to be done on the raw data which is collected from your smart devices and convert them into useful business information. In this blog post, we will see how Oracle Internet of Things Cloud Service collect the data from smart devices and convert them into business information by leveraging Oracle Business Intelligence Cloud Service and enable business users to act pragmatically.

Oracle Internet of Things Cloud Service


Typical Oracle IOT deployment consist of IOT enabled Devices, IT Cloud Service and business applications.



Three core elements of Oracle Internet of Things Cloud Services which glue all different component together are –

  1. Connect – reliable, secure messaging with device
  2. Analyze – incoming data stream at real time and Visualize data with Big Data & BI Cloud Services
  3. Integrate – IOT data with enterprise applications

For more details –


Technical Architecture

To implement our use-case, our IOT infrastructure connect and push data to Business Intelligence Cloud Service thru Integration capabilities provided out of box in Oracle Internet of Things Cloud Service.

Technical Architecture for the same will look like this -



Interaction between components is as below –

  1. Devices are connected either directly or thru gateway device to Oracle Internet of Things Cloud Service and continuously sends data over internet.
  2. Oracle Internet of Things Cloud Service capture the device data and provide real time analysis.
  3. Oracle Internet of Things connect to Oracle Business Intelligence Cloud Service and send device data to enabled BICS do the historical data analysis and present business user with key information about the device health and required action to take.


Components Involved and Interaction

In order to work with this, you will need account for following

  1. Oracle Internet of Things Cloud Service
  2. Oracle Business Intelligence Cloud Service
  3. Smart Device


Let's Do It


Let’s first understand steps required to implement the use-case –



Creating IOT Application


1. Open IOT Cloud Service instance and login,

2. In the Dashboard, select the Application tab at the top of the screen


3. Click Create Application



4. Enter details for Name and description


5. This will create the application with the given name and will get displayed on the Application Dashboard.



This completes the IOT application creation in Oracle Internet of Things Cloud Service.


Associating Device Model


1. Open the Application Dashboard by clicking “Application” at the top and then click on the application created in the last step


2. Click on the Device Model available in the left pane and then “Choose Device Model”



3. Select “HVAC Device Model” and Click Done.



At this stage, our Application is associated with Device Model which identify the type of devices associated with this Application.


Capturing Data Stream


In order to enable real time analysis, after associating Device Model with the Application, we need to associate a Data Stream with the application. Here are steps –


1. Click on “Data and Exploration” in the left pane and then “Exploration”


2. Create new Exploration Source and bind it to required data model. In our case, bind it with the “HVAC device Model”. Add Metadata for additional device data which you want to add to the stream of data.



Once Exploration Source is created, create the Exploration


1. Click “Add”


2. Add required Details and Select previously create “Exploration Source”


3. Click Confirm.


Now we have our IOT Application associated with Device Model and Exploration. Exploration can be used to analyze the data at real time.


Create Integration with Business Intelligence Cloud Service


For historical data analysis, integrate the IOT Application with Business Intelligence Cloud Service, using below steps –


1. From the Application, Click on “Integration” available in left pane


2.Click “+” sign and then choose “Business Intelligence Cloud Service”



3. Enter Details for BICS and click Create



     URL – URL for the BICS Instance (

     Identity Domain – BICS Identity Domain

     Username – BICS user

     Password – Password for the BICS user


4. Newly create integration will look like this, please note that this is not yet associated with any data stream


5. Select and Edit this Integration to add data stream by providing details for BICS Table Name, Message Format and Annotations


6. Once done, you will see Integration is fully configured and marked green



At this point we have our IOT application configured to listen to HVAC device, collect the data stream show real time analysis and forward it to BICS for historical analysis.


Register Device with IOT Cloud Service


Each device with communicate with Oracle IOT cloud Service must be registered and activated before any data messages can be transmitted. To register a device with IoT –


1. From the top menu, click on Devices tab


2. Click Registration on the left hand pane


3.On the Device Registration screen, click Register Single Device.


4. Enter details and click Register


5. Please make a note of Device ID and Shared Secret which you will need later to activate the device. Click Finish



The Device is now registered with Oracle IOT Cloud Service. With the Device ID and Shared Secret, you can activate the device. Once activated, device can communicate with the IoT Cloud Service and send data to IoT Cloud Service.

Moving Data to BICS


Once you have the Integration set-up in your IOT application with BICS, moving data to BICS is simple.

1. Go to your Integration and click on “Sync Now” button



This will sync data in given table name (while configuring stream in the BICS Integration) in BICS database


Analyzing Data in BICS


Once you sync data from IOTCS to BICS, you can see the data in BICS and analyze it to provide useful information to the business user. For the sake if simplicity, I am going to show max value of some attribute for each device.


To view data in BICS

1. Login to the BICS Analytics App and click on Modeler


2. In the Database pane, you will find the table named “HVAC_MESSAGES” which was given when configuring the stream with the BICS Integration.



3. Click “Lock and Edit” at the right to edit the model.

4. Click on the “HVAC_MESSGES” table and then click “Add to Model”. Select “Add as Fact and Dimension Tables”


5. Give names to Fact and Dimension Table and click “Add”



6. Click on “Analyses” on the Top menu



7. Click on Create Analysis on right and select the Model. This will open a new window to analyze the data. In the “Criteria” tab, select the data









8. Click on the gear icon on the OUTPUTTEMP field and Edit the Column Formula as MAX(“IOT_HVAC_FACT”,”OUTPUTEMP”) for maximum temperature of the given device.


9. Click on the “Result” tab to see the tabular data –


10.  Create Vertical Bar Graph to represent the above data


11. Graphical representation of the data will come as


12. Save the Analysis by clicking “Save” Icon at right and saving in the Shared Folder



Providing analysis to Business User


Reports can be provided to business users by creating Dashboard and including required data into them. To create Dashboard to display IOT data –


1. Click on “DashBoards” in BICS Analytics App


2. Click on Create Dashboard button on the right and provide details


3. Dashboard Editor will open and you can add the previously created analysis by finding it in “Catalog” and dragging it in main frame


4. Click Save Icon to save the Dashboard.

5. This Dashboard can be shared and viewed to view the information about HVAC devices which is collected from IOTCS






Analysis of data collected from your smart devices and its availability to business users is critical aspect out of any Internet of Things Deployment and Oracle Cloud PaaS Services work together to maximize your investment in this area. Real time and historical analysis of data comes out of the box with Oracle’s Internet of Things Cloud Service, enable users to take critical and timely business decisions.


To learn more about Oracle Internet of Things Cloud Services visit –


** The views expressed in this post are my own and do not necessarily reflect the views of Oracle. ** 

Social Objects in Oracle Social Network Cloud are generally used to add Collaboration features to your Business Objects i.e. System of record (for e.g. to carry out a conversation regarding a particular opportunity in Sales Cloud).  Social Objects have their own metadata (attributes), "wall", a documents area where you can upload documents, and provisions to attach other related conversations/objects.


You can limit visibility or share a Social Object between other people in your organization by adding individuals or groups.


For simple scenarios, where not much relational data is needed, a Social Object can also directly be used as a system-of-record.


In this blog post I will explore one such case - using the Social Object API to implement a simple Kanban board with collaboration features.


Creating a Social Definition

The first step is to create a Social Definition of a Kanban task.  We will call it "KanbanTask" and have three attributes in it

- Status (TODO, DONE, DOING)

- Title

- Description

- Assigned


The definition of a Social Object can be uploaded by an Administrator using the Social Network UI ( Administration -> Social Objects -> Create ).  This can also be done programmatically using REST APIs.  If you have a staging instance, this can also be done via the Social Definiton Builder available at https://<staging-instance>/osndevelopers/ui/integrations/integrations.jsp.  This is a one time activity and I am using the upload option to seed a simple Social Definition. 

<?xml version="1.0" encoding="UTF-8"?>
 <ModulePrefs title="KanbanTask" description="A Kanban Task representation" height="175">
 <Require feature="rpc" />
 <Require feature="waggle" />
 <Require feature="jquery" version="1.3.2" />
 <Require feature="jquery-ui" version="1.8.12" />
 <Require feature="osnutils" />
 <Locale country="ALL" lang="all">
            <msg name="">Tools</msg>
            <msg name="">tools</msg>
            <msg name="">KanbanTask</msg>
            <msg name="">kanbantask</msg>
            <msg name="">KanbanTasks</msg>
            <msg name="">kanbantasks</msg>
            <msg name="osn.gadget.create.short">New Kanban task</msg>
            <msg name="osn.gadget.create.long">Create a new Kanban Task</msg>
            <msg name="osn.gadget.create.tooltip">Create a new Kanban Task</msg>
            <msg name="">Title</msg>
 <msg name="">Status</msg>
            <msg name="">Assigned</msg>
            <msg name="">Description</msg>
 <Locale country="ALL" lang="de" />
 <Locale country="ALL" lang="es" />
 <Locale country="ALL" lang="fr" />
 <Locale country="ALL" lang="it" />
 <Locale country="ALL" lang="ja" />
 <Locale country="ALL" lang="ko" />
 <Locale country="BR" lang="pt" />
 <Locale country="CN" lang="zh" />
 <Locale country="TW" lang="zh" />
 <ConversationTypePrefs group="Tools" group_order="1" creatable="true" updateable="true" renameable="true" discoverable="false" closeable="true" deletable="false" customizable="true" ui="true" analytics="false" analytics_outcome="false" scoping="false" integration_adapter="none">
 <Field property_key="TITLE" type="STRING" case_sensitive="false" required="false" read_only="false" external="false" analytics="false" display_in_detail="true" display_in_summary="true" display_in_digest="false" filterable="false" sortable="true" units_prefix="false" not_nullable="false" />
 <Field property_key="DESCRIPTION" type="STRING" case_sensitive="false" required="false" read_only="false" external="false" analytics="false" display_in_detail="true" display_in_summary="true" display_in_digest="false" filterable="false" sortable="true" units_prefix="false" not_nullable="false" />
 <Field property_key="STATUS" type="STRING" case_sensitive="false" required="false" read_only="false" external="false" analytics="false" display_in_detail="true" display_in_summary="false" display_in_digest="false" filterable="false" sortable="false" units_prefix="false" not_nullable="false" />
 <Field property_key="ASSIGNED" type="STRING" case_sensitive="false" required="false" read_only="false" external="false" analytics="false" display_in_detail="true" display_in_summary="false" display_in_digest="false" filterable="false" sortable="false" units_prefix="false" not_nullable="false" />

 <Content type="html"><![CDATA[ 
<script type="text/javascript"> gadgets.util.registerOnLoadHandler(function() { osnutils.gadget.load(); }); </script>


Save the XML to the local directory and upload it via the Social Definition screen.




Once this XML containing the social Object Definition is uploaded you can see the option to create a new “Kanban Task” from the Navigation menu on the left hand side. Note that the Social Object “KanbanTasks” is  in a Group called Tools, since we specified the same in the XML.




Creating and Updating a Social Object

Navigating to this new menu option will take you to the “Kanban Task” Social Objects page, where you have options to create, update or view the social objects.  You can also see the type of the social object in the URL when you navigate to this page




Here, 13452 is the type id of the Social Object "KanbanTask"


Create a new "KanbanTask" by clicking on the "New" button.  This will open the standard OSN gadget window where you can give a title, and manage membership to the new object that will be created.




The "KanbanTask" will be created with default values of the attributes that we used in the definition.  This is how it will look like in the UI.



Now you can "Edit" the Social Object to edit these values.  Any changes to the Social Object Data will be visible in the Wall and the members assigned to the Social Objects can collaborate and share documents pertaining to the Social Object.


REST interface

The OSN comes with a exhaustive REST API catalog to programmatically perform various tasks and can be referred here. Let us retrieve the Social Object we have just created.


The first API to be used for establishing a connection to the Social Network Cloud Service is the connections API.  This API will create a new connection or determine if there is an existing connection and also return a cookie for further communication.


POST http://<host-name>/osn/social/api/v1/connections HTTP/1.1

Accept-Encoding: gzip,deflate

Content-Type: application/json

Content-Length: 57


                "name" : "tenant.admin",

                "password" : "abc123"



and the response - a whole bunch of attributes corresponding to the logged


HTTP/1.1 200 OK

Date: Tue, 28 Jun 2016 02:02:30 GMT

Set-Cookie: OAMAuthnCookie_<hostname>:443=C3TVf6ypnEzq8RZ9G3wjax6Gq.....;

X-ORACLE-DMS-ECID: 005D^o7XiLt6eLG_IxG7yf0006nT00001R

X-Powered-By: Servlet/2.5 JSP/2.1

X-Content-Type-Options: nosniff

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Transfer-Encoding: chunked

Content-Type: application/json;charset=UTF-8

Content-Language: en



  "user" :


    "id" : "10190",

    "name" : "tenant.admin",

    "displayName" : "tenant.admin",

    "objectType" : "waggle/user",

    "createdByID" : "10041",

    "createdByUserName" : "System",



  "apiVersionMinimum" : 6076,

  "apiRandomID" : "b375e527c6e1bbf3b1f2f7fb96184f3e",

   "isTerseMode" : false



There are two things that need to be passed i the subsequent requests - the cookie and the apiRandomId.  The apiRandomID should be passed in the X-Waggle-RandomID parameter in the header


Here are the headers, payload for the request for getting all Social Objects.  You can add a filter query parameter to limit the response to certain variables (e.g. getting all Social Objects that are applicable to a certain user as shown here)


GET  /osn/social/api/v1/socialObjects ?filter={"commonMemberID" : "10190"}

HTTP/1.1 Accept-Encoding: gzip,deflate

cookie: OAMAuthnCookie_<hostname>:443=C3TVf6ypnEzq8RZ9G3wjax6Gq.....;

X-Waggle-RandomID: b375e527c6e1bbf3b1f2f7fb96184f3e

Here is the response containing the Social Object just created.



   "hasMore": false,

   "items":    [


         "id": "13455",

         "name": "UI1 - Coding",

         "objectType": "waggle/conversation",

         "createdByID": "10190",

         "createdByUserName": "tenant.admin",



         "nFollowups": 0,

         "fields":          [


               "name": "ASSIGNED",

               "value": "Aparna"



               "name": "DESCRIPTION",

               "value": "UI coding for task 1"



               "name": "STATUS",

               "value": "TODO"



               "name": "TITLE",

               "value": "Task1"










Embeddable UI

The OSN Web UI can be directly displayed in other applications.  This can be done by using the Social Plugins which are UI components embeddable in other applications.

The view to be shown is inserted after the root portion of the URL.  So




displays the view for the conversation id 9877


The particular view can be further customized as to not show certain options



will hide the navigation menu and sidebar from the conversation list displayed.

For full reference please consult the Social Plugin documentation available on https://<hostame>/osn/web/cList/api 


Wrapping it all together


The output of the REST APIs and the embeddable UI can now be used in the visualization of choice.  For my project, I have created a simple JET application that will be deployed in a Java Cloud Service - SaaS Extension which is in the same identity domain as the Social network Cloud to achieve SSO.  The JET application first retrieves the Social Objects of type KanbanTask for the logged in user and then arranges them on a simple Kanban Board.  The tasks can be dragged and dropped in the To do, Done and In Progress areas. Clicking on any task will load the Social Object page for that particular task in the right hand menu.




The views expressed in this post are my own and do not necessarily reflect the views of Oracle.