Introduction

Oracle Integration Cloud provides a graphic design tool to help users construct XSLmapping. The image below shows a typical graphic mapping construct.

The above mapping is for transforming the source object:

{
  "nameSource" : "close",
  "parametersSource" : [ {
    "closedDateSource" : "2019-09-27",
    "closeReasonSource" : "ORA_UPGRADE",
    "closeCreditMethodSource" : "ORA_FULL"
  }, {
    "closedDateSource" : "2019-09-28",
    "closeReasonSource" : "ORA_UPGRADE",
    "closeCreditMethodSource" : "ORA_FULL"
  } ]
}

to a target object:

{
  "name" : "close",
  "parameters" : [ {
    "closedDate" : "2019-09-27",
    "closeReason" : "ORA_UPGRADE",
    "closeCreditMethod" : "ORA_FULL"
  }, {
    "closedDate" : "2019-09-28",
    "closeReason" : "ORA_UPGRADE",
    "closeCreditMethod" : "ORA_FULL"
  } ]
}

As one can see both the source and target JSON objects are as normal as we can expect. The OIC graphic mapping tool handles this mapping with ease. However, in some cases, we are forced to deal with some unconventional JSON objects. 

Unconventional JSON Objects

One example of an unconventional JSON objects is in the Oracle Application Could Subscription Management REST API. For example, to close a subscription via a REST call, the request payload much be in the following format:

{
  "name" : "close",
  "parameters" : [ {
    "closedDate" : "2019-09-27"
   }, { 
    "closeReason" : "ORA_UPGRADE"
   }, {
    "closeCreditMethod" : "ORA_FULL"
   }]
}

This is not a normal JSON object because each element in the array "parameters" has a different schema. Relying on the mapping design tool solely will produce an unexpected JSON object. A solution to this problem is that we manually modify the transformation in XSL code to achieve the desired outcome. Let's use the close subscription REST call as an example to demonstrate how we can make the mapping work with some additional manual steps.

Map Unconventional Objects

From a real customer use case, we have the following input (partial) to OIC:

{
    "nameSource" : "close",
    "closedDateSource" : "2019-09-27",
    "closeReasonSource" : "ORA_UPGRADE",
    "closeCreditMethodSource" : "ORA_FULL"
}

The orchestration needs to call Subscription Management REST API to close a subscription. The REST API request payload is in the following format: 

{
    "name" : "close",
    "parameters" : [
      {"closedDate" : "2019-09-27"},
      {"closeReason" : "ORA_UPGRADE"},
      {"closeCreditMethod" : "ORA_FULL"}
    ]
}

While the mapping design tool does not give us a complete solution in creating the mapping we want, we can still leverage the tool to make our manual steps a little easier. So we will start with the design tool.

Initial Mapping with the Design Tool

The following image shows a first mapping constructed with the design tool.

Without any modification, the above mapping from the design tool results in the following JSON object:

{
  "name" : "close",
  "parameters" : [ {
    "closedDate" : "2019-09-27",
    "closeReason" : "ORA_UPGRADE",
    "closeCreditMethod" : "ORA_FULL"
  } ]
}

It is clearly not the payload we want. Now let's switch to code view by clicking the Code button as circled in the above image. The following image shows the main part of the original mapping code:

As we can see, all three properties are grouped into a single "parameters" array element. So we need to manually break them up so that each property is in its own "parameters" array element like the following:

With the above simple modification, we can now get our desired payload.

Conclusion

This blog shows a way to create mappings to unconventional JSON objects in OIC with some manual modifications. The example is quite simple but we can create very complex mappings in the code view. The graphic design tool might not be able to map some unconventional objects correctly. It is still helpful in creating an initial mapping based on which we can add manual modifications.