Handle dynamic params in metadata for REST connectors in OSB 12C

In this post, we will learn how to get the value of some path parameters from the URI of a REST Service using OSB 12C. There we go:

Use case

First, lets think that we have to consume a sample REST service to create one employee in a specific organization, so we will have a dynamic path parameter after organizations that we are going to send in the URI.





   "fullName":"Christopher Laurente",

Then we start, open JDeveloper (In my case is 12.2.1), create a Service bus project and add a Rest component to External services in the composite as the image below.

Set the name, for instance CompaniesAPI and check the box “Reference will be invoked by components using WSDL interfaces”.

Set the Base URI as https://RestServices.com/api and add a Resource Path as organizations/{organization_id}/employees. See the image below.

Then create a Operation Binding, call it CreateEmployee and select the HTTP Verb as POST.

Now, we need to reference the path param called organization_id, for this we are going to use the variable $property according to oracle documentation https://docs.oracle.com/middleware/1213/osb/develop/GUID-C346DF7D-041D-4E10-BE1C-451F50719106.htm#OSBDV88240

The variable called organizationId will be set in the metadata of the outbound request as the following structure:

   <headers >
   <ctx:user-metadata name="organizationId" value="1" />

One of the challenges that I got was that I could not insert the metadata directly into the outbound variable, because I got CData error everytime that I tried. So what I did was assigning the whole value of the outbound in an auxiliar variable, insert the metadata into that aux variable and replace the outbound with the value of the auxiliar outbound.

Assign to auxiliar variable

Insert metadata

Replace Outbound


I’m gonna say that I had to review oracle documentation to understand how to use this REST component correctly and not always will be necessary to use this solution to send dynamic params in the URI (even for query params), because if is possible to use the content body to send these params then it will be straightforward to manage them rather than the solution that I described above.