Transform task does not have the facility to let the user choose which target interface to use when there are multiple target interfaces present in a mediation path.

Transform task does not have the facility to let the user choose which target interface to use when there are multiple target interfaces present in a mediation path.

book

Article ID: KB0090830

calendar_today

Updated On:

Products Versions
TIBCO ActiveMatrix Service Grid -
TIBCO ActiveMatrix BusinessWorks Service Engine -
Not Applicable -

Description

Description:
Workaround options for Transform Activity when dealing with multiple target interfaces.

Issue/Introduction

Transform task does not have the facility to let the user choose which target interface to use when there are multiple target interfaces present in a mediation path.

Resolution

Problem Description
***********************
Transform task does not have the facility to let a user choose which target interface to use when there are multiple target interfaces present in a mediation path.

Example: The sample mediation project has one mediation interface, Sample1, and two target interfaces, Sample1 and Sample2. The mediation is wired to the Sample1::OperationRequest. However, it needs to make an intermediate call to the Sample2::OperationRequest service using the invoke operation, and then log this intermediate request using the Log Mediation Activity. The issue is that the transform task always chooses the operation that the mediation is mapped to (Sample1) and does not have the facility to let users choose which target interface to transform to. Hence, the user is not able to transform/log the request for the intermediate interface call (Sample2).

Suggested Workarounds
*****************************
Approach 1:
- User Render XML task paired with the Parse XML task. The pre-requisite is that the input schema definition must be stored in an XSD within the user's project since the "Render XML" task needs the schema definition for the input data. 

Example: A new schema file NewXMlSchema.xsd is created for the Sample2 operation inputreq/outputreq, and have it imported into the wsdl. [Note: This step can be ignored if XSD is already externalized]. Now the user can use the RenderXML task and browse the input schema (defined for Sample2 operations) for the request and then can prepare the input for the target operation under the Input tab. Next, a parseXML task can be used and the renderxmlstring can be mapped to output to parsexmlstringinput under the Input tab. The log task will then allow logging the parse data which would log the sample operation input prepared using render XML task.

Approach2:
-Instead of using Invoke task to make the intermediate call, you can set the dynamic reference to the target service (for the intermediate call). In that case you just need to mention your application name and service name (for the second interface) so that it will be invoked dynamically at runtime. In order to prepare/transform the input, you can introduce a mediation flow for your second interface being invoked at runtime.

For the above (example):

- Use the Set Dynamic ref task instead of the Invoke task and configure the application name as "Sample2" and service name as "SampleService".
- Introduce another mediation flow for this second interface call (Sample2 mediation) where you can prepare/transform your input accordingly.
- Design your Sample2 composite with the service name as "SampleService" (same as configured in dynamic ref task) and select the corresponding mediation implementation.

So instead of Invoking the Sample2 target interface using the Invoke call, the composite application "Sample2" configured in the dynamic ref task will be called at runtime and this composite has the mediation flow defined for preparing the input as required.