Processing responses from a CORBARequest node

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

• 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)