Siva's Blog

In the last post, we have seen that calling proxies send the proxy name as a payload to CommonPS as shown below.

<Payload>
    <ProxyName>PS_A</ProxyName>
    <AuditPayload>
        <Date>2011-05-23</Date>
        <Description>Audit Data</Description>
    </AuditPayload>
</Payload>

This approach has a problem that we have to manually change the ProxyName element in the payload every time we rename the proxy service. To overcome this problem we can use the XQuery expression $inbound/@name to get the proxy name. This would give the proxy name in the following format.

ProxyService$<fully qualified path of project separated by $>

So in PS_A, modify the assign activity that is present in the request pipeline as shown below.

Using the expression $inbound/@name in the above payload will be converted into the following once it reaches the CommonPS.

<Payload>
    <ProxyName name="ProxyService$TestConfigProject$PS_A"/>   

<AuditPayload>
        <Date>2011-05-23</Date>
        <Description>Audit Data</Description>
    </AuditPayload>
</Payload>

This triggers a change in the message flow of CommonPS as well. So modify the assign activity which is shown below with a new expression to get the proxy name.

Modify the expression in this assign activity to the following.

                 fn:tokenize($body/Payload/ProxyName/@name, ‘\$’)[last()]

Now deploy both of the OSB projects(TestConfigProject and Project_A) and run PS_A and PS_B once by setting the Flag value as ‘Y’ and once with value ‘N’. Observe that the auditing is happening only when the Flag value is set to ‘Y’ as observed in earlier scenario.

We often see the following scenarios in any typical software application development or deployment and OSB is also not an exception from this perspective.

– There will be few things or parameters that have to be modified depending on the environment that we are deploying to.

– Provision for switching on and off of the some functionality based on the requirement. For example, a service that logs some information into database should be configured to switch on and off when required.

In these scenarios, We can leverage the XQuery resources in OSB to put all of our configurable properties. This post explains the following things to achieve this functionality:

         – Creating the XQuery Resource with configurable properties.

         – Using the XQuery Resource in Proxy Service Message Flow

Creating the XQuery Resource

Create any OSB project (TestConfigProject), right click on the TestConfigProject and select New –> XQuery Transformation as shown below.

Give the filename as ‘ConfigXML’ and click on Next.

Select anytype, add it and click on Next.

Again select anytype, add it and click on Finish.

Following screen will appear after clicking on the ‘Finish’ button.

Go to ‘Source’ tab on clicking and delete all the contents.  Assume that we want to specify the configurable property for each and every proxy service present in our OSB configuration project. So we could paste the following contents in our XQuery resource. This XML structure allows us to add as many properties we want for each proxy service.

<ProxyServiceList>
    <ProxyService name="PS_A">
        <Flag>Y</Flag>
    </ProxyService>
    <ProxyService name="PS_B">
        <Flag>N</Flag>
    </ProxyService>
</ProxyServiceList>

Using the XQuery Resource in OSB Proxy Service

Consider a scenario where the proxies PS_A and PS_B have to call some other proxy CommonFuncPS which does the actual activity of inserting some auditing information in database. And this functionality should be configurable so that we can enable/disable the auditing whenever required.

We can use the above XQuery resource for configuring this functionality. The flag value ’Ý’ indicates that the auditing should happen and the value ‘N’ indicates that auditing should not happen.

To achieve this, let’s create another proxy service CommonPS that checks for this configuration property value and calls CommonFuncPS based on the value given in the XQuery resource. The following screenshot shows all the proxy services that are involved in this exercise and let’s create all proxy services as ‘Any XML Service’ for simplicity.

CommonPS Message Flow

Since this proxy has to determine the calling proxy, all other proxy services has to send its name along with the payload that has to be inserted into database. So assume that following is the structure of the request message that we agreed on

<Payload>
    <ProxyName>PS_A</ProxyName>
    <AuditPayload>
        <Date>2011-05-23</Date>
        <Description>Audit Data</Description>
    </AuditPayload>
</Payload>

Go to the message flow of the proxy service and insert a pipelinepair Node and Stage and insert an assign activity. Click on the ’Éxpression’ in the properties and select XQuery resource as shown below.

Select the XQuery resource by clicking on Browse button as shown below.

Click on OK button after selecting ConfigXML.xq resource in the popup window and give the assign variable as varConfigPayload.

Create another assign activity to get the proxy name that is been passed in the input and use the expression as shown below and assign this value to a variable varProxyName.

We have a variable where the configuration information is stored for all the proxies and also we have a variable which gives the information about calling proxy. Now we need to check whether audit flag is enabled or not before calling the CommonFuncPS. So insert If-Then activity from Stage Actions –> Flow Control as shown below.

Enter the expression for if condition as shown below.

Now insert a service callout to call the CommonFuncPS and set the variables as shown below. Since this article is about the configurable properties we will not look at the actual message flow of CommonFuncPS.

Insert another assign activity in the request pipeline of the service callout and populate the variable varRequestPayload by extracting the auditing payload from the body variable as shown below:

We have done with the message flow of CommonPS and we will see the message flow of the calling proxies.

Calling Proxies (PS_A or PS_B) Message Flow

Calling proxies message flow is very simple which will have just service callout to CommonPS proxy service as shown below.

Insert an assign activity in the request pipeline to populate the request variable of above service callout and pass the actual proxy name for ProxyName element as shown below.

Now deploy both of these OSB projects and run PS_A and PS_B once by setting the Flag value as ‘Y’ and once with value ‘N’. Observe that the auditing is happening only when the Flag value is set to ‘Y’.

This way an XQuery resource can be used to define all the configurable properties for individual proxies existing in your OSB configuration project. The XML used in this demonstration is also extensible and number of properties can be added as and when required.