IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Processing responses from a CORBARequest node

Configure the CORBARequest node to define the location to which responses are sent.

Before you start:

Complete the tasks that are described in the following topics:

The CORBARequest node has three output terminals:

Out: For a successful invocation of the operation.
Error: If a CORBA system exception or user-defined exception is issued.
Failure: If a failure occurs in the node; for example, if the node cannot communicate with the naming service or it receives an incorrect message.

You can select the location to which to send the response by configuring the Output data location property on the Result tab. This property specifies the message tree location to which the CORBARequest node puts output. The output is put under the DataObject domain. For more information, see Combining a result message with an incoming message.

Processing successful calls
When a call is successful, the resulting message is propagated to the Out terminal. Inside the tree is a top-level element named InterfaceName.OperationNameResponse. Under this type is the return type of the operation (named _return) and every inout or out parameter. In parameters are not propagated because they do not change.

A mixture of in inout and out parameters
Here is an example IDL file:
```
interface 

ExampleOne {
   string exampleOneOperation(in string inparam, out string outparam, inout string inoutparam);

}
```
You receive the parameters outparam and inoutparam under the top-level element ExampleOne.exampleOneOperationResponse.
Here is an XML example:
```
<ExampleOne.exampleOneOperationResponse> 
	<_return>The operation return value</_return>
	<outparam>value from corba app</outparam>
	</inoutparam>your value changed by the corba app<inoutparam>
</ExampleOne.exampleOneOperationResponse> 
```
Out and inout parameters
Here is an example IDL file:
```
interface 

ExampleTwo {
   string exampleTwoOperation(out string outparam, inout string inoutparam);

}
```
The removal of the in parameter makes no difference to the message that is propagated from a CORBARequest node because in parameters are not propagated.
Here is an XML example:
```
<ExampleTwo.exampleTwoOperationResponse> 
	<_return>The operation return value</_return>
	<outparam>value from corba app</outparam>
	</inoutparam>your value changed by the corba app<inoutparam>
</ExampleTwo.exampleTwoOperationResponse> 
```
In parameters only or no parameters

If the operation contains no parameters, or in parameters only, you receive the _return value under the top-level element.
Here is an example IDL file:
```
interface 

ExampleThree {
   string exampleThreeOperation(in string inparam);

}
```
Here is an XML example:
```
<ExampleThree.exampleThreeOperationResponse> 
	<_return>The operation return value</_return>
</ExampleThree.exampleThreeOperationResponse> 
```
No return type (void) and no inout or out parameters

If the operation that you are calling has no return type (void) and no inout or out parameters, no values are returned from the CORBA application to put in the tree. In this case, only the top-level element is created.
Here is an example IDL file:
```
interface 

ExampleFour {
   void exampleFourOperation(in string inparam);

}
```
Here is an XML example:
```
<ExampleFour.exampleFourOperationResponse> 
</ExampleFour.exampleFourOperationResponse> 
```
Processing user-defined exceptions and CORBA system exceptions
When a CORBA user-defined exception or a CORBA system exception occurs, a message is propagated to the Error terminal. CORBA system exceptions have a standard shape and look like this:
In the IDL file:
```
exception SystemException { // descriptive of error

	unsigned long;      // more detail about error 
	CompletionStatus;   // yes, no, maybe 
}
```
In the tree:
```
<SystemException> 
	<minor>10</minor>
	<completed>maybe</completed>
</SystemException> 
```
The top-level element is the name of the CORBA system exception that is issued. The structure of a user-defined exception is based on the IDL for the exception. Here is an example:
In the IDL file:
```
		exception BadRecord { 
	string why;

}; 
```
In the message:
```
<BadRecord> 
	<why>reason text</why>
</BadRecord>
```
As you can see from this example, the structure of the message is based on the exception, and is not qualified by the operation that was being called.
Handling failures in the node
Any failures are propagated to the Failure terminal. Possible failures include:
- Inability to communicate with the CORBA server
- Inability to communicate with the CORBA naming service
- Invalid body (including the wrong top-level element or missing parameters)

bc22460_.htm |

Last updated Friday, 21 July 2017