5 Creating and Modifying Simulator Definitions

This chapter describes how to create and modify simulator definitions. It also provides instructions for how to provide multiple request and response message sets in a single simulator definition, how to create a simulator definition that supports chatty services, and how to send dynamic responses in a simulator response.

A simulator definition is created by the Composite Application Validation System (CAVS) user to simulate a particular service in an Oracle Application Integration Architecture (AIA) integration or a participating application. A simulator receives data from the tested web service and returns predefined data so that the tested web service can continue processing.

This chapter includes the following sections:

• Section 5.1, "How to Create a Simulator Definition"

• Section 5.2, "How to Modify a Simulator Definition"

• Section 5.3, "How to Provide Multiple Request and Response Message Sets in a Single Simulator Definition"

• Section 5.4, "How to Create a Simulator Definition that Supports Chatty Services"

• Section 5.5, "How to Send Dynamic Responses in a Simulator Response"

5.1 How to Create a Simulator Definition

To create a simulator definition:

1. Access the AIA Home Page. In the Composite Application Validation System area, click the Go button. Select the Definitions tab. Click the Create Simulator button. The Create Simulator page displays, as shown in Figure 5-1 and Figure 5-2.

   Figure 5-1 Create Simulator Page (1 of 2)

   
   

   Figure 5-2 Create Simulator Page (2 of 2)

   
   

2. Use the page elements on the Create Simulator page to create simulator definitions. Available elements are discussed in Table 5-1.

Table 5-1 Create Simulator Page Elements

Element	Description
Id	Upon saving the simulator definition, a unique key identifier is assigned to the simulator definition.
Name	Enter the descriptive name you want to use for the simulator definition.
Type	Displays the type of definition you have chosen to create. On the Create Simulator page, this value will always be set to Simulator.
Service Type	Select the business service pattern of the web service the simulator definition is simulating. Synchronous (request-and-reply) Notify (asynchronous request-only) Asynchronous two way
Service Name	Enter the name of the web service that you want to simulate using the simulator definition.
Service Version	Enter the version of the web service you want simulate using the simulator definition.
Process Name	Enter the name of the process that includes the web service that you want to simulate using the simulator definition.
PIP Name (Process Integration Pack name)	Enter the name of the PIP that includes the web service that you want to simulate using the simulator definition.

Test Messages

Use the Test Messages group box to generate XPath values based on provided request XML message text. By default, SOAP envelope XML text is provided in these fields. You can paste XML text within this default SOAP envelope, or paste your own XML text already enclosed in an envelope into these fields.

For more information about how to create simulator request and response messages that hold multiple sets of test data in a single definition, see Section 5.3, "How to Provide Multiple Request and Response Message Sets in a Single Simulator Definition."

For more information about how to create simulator request and response messages that support chatty service conversations, see Section 5.4, "How to Create a Simulator Definition that Supports Chatty Services."

Available elements in the Test Messages group box are discussed in Table 5-2.

Table 5-2 Test Messages Group Box Elements

Element	Description
Expected Request Message	Entering request message XML text facilitates the generation of XPath values that are used to match a received request with this simulator's expected request, as well as to validate values in this received request message. That is, the XPath values you supply provide a signature for the simulator definition that the simulator service attempts to match with arriving request actions. In addition to enabling the simulator service to match a test request with a simulator definition, the XPath criteria you provide can also serve to validate data sent in the test request. If a simulator has been directly designated for use in the AIAConfigurationProperties.xml via the Routing Configurations page, the simulator definition will be identified directly. However, after the simulator has been identified, there may be multiple requests within it. If so, the XPath key field values provide an efficient search method for request matching. For more information about the Routing Configurations page, see Chapter 8, "Defining CAVS Routing Setup IDs." You can enter expected request message XML text on this page and click the Generate Xpath button on the Modify Simulator Definition page to generate XPath values used to validate the actual request sent by the test definition. You may also choose to manually enter or modify the XPath values directly on the Modify Simulator Definition page. You do not need to enter request message XML if you are manually entering XPath values directly on the Modify Simulator Definition page. You may choose to copy and paste messages from the BPEL Console, instead of manually entering them. For more information, see Section 2.5.1, "How to Obtain Message XML Text from a BPEL Process."
Response Message	Entering response message XML text for a simulator definition is required when the Service Type field value is set to Synchronous or Asynchronous two way. Enter the XML text of the response message that you want to use for the simulator definition. This response message should mimic the actual response message that would be sent by the service that the simulator definition is simulating. This text box is hidden when the Service Type field value is set to Notify. In this case, a response message is not a simulator requirement. You may choose to copy and paste messages from the BPEL Console, instead of manually entering them. For more information, see Section 2.5.1, "How to Obtain Message XML Text from a BPEL Process."
Cancel	Click to discard any updates you have made and return to the Definitions page.
Next	Click to save entries on the Create Simulator page and go to the Modify Simulator Definition page, where you can generate XPaths and further edit and manage the simulator definition.
Save	Click to save entries on the Create Simulator page and return to the Definitions page.

5.2 How to Modify a Simulator Definition

To modify a simulator definition:

1. Access the Modify Simulator Definition page, as shown in Figure 5-3, Figure 5-4, Figure 5-5, Figure 5-6, and Figure 5-7.

   Access the page using one of the following navigation paths:

   • Access the AIA Home Page. In the Composite Application Validation System area, click the Go button. Select the Definitions tab. Click the Create Simulator button. Enter required values on the Create Simulator page and click Next.

   • Access the AIA Home Page. In the Composite Application Validation System area, click the Go button. Select the Definitions tab. Click an Id link for an unlocked simulator definition in the Search Result Selection grid on the Definitions page.

   • Access the AIA Home Page. In the Composite Application Validation System area, click the Go button. Select the Instances tab. Click a Definition Id link for an unlocked simulator definition on the Instances page.

   Figure 5-3 Modify Simulator Definition Page (1 of 5)

   
   

   Figure 5-4 Modify Simulator Definition Page (2 of 5)

   
   

   Figure 5-5 Modify Simulator Definition Page (3 of 5)

   
   

   Figure 5-6 Modify Simulator Definition Page (4 of 5)

   
   

   Figure 5-7 Modify Simulator Definition Page (5 of 5)

   
   

2. Use the page elements on the Modify Simulator Definition page to modify a simulator definition. The page displays values you defined for the simulator definition. You can modify the values in editable fields.

   Most of the elements on this page also appear on the Create Simulator Definition page and are documented in Section 5.1, "How to Create a Simulator Definition." Any additional elements are discussed here in Table 5-3.

Table 5-3 Modify Simulator Definition Page Elements

Element	Description
Actions	Select the action you want to take with the simulator definition. Lock: Select to lock the simulator definition and view the simulator definition on the View Simulator Definition page. A locked definition cannot be edited. Duplicate: Select to duplicate the simulator definition. The duplicate definition is created using the exact values of the original, with the exception of being given a unique Id value.
Cancel	Click to discard any updates you have made and return to the Definitions page.
Apply	Click to apply and save any changes you have made to values on the page.
Save	Click to save entries on the page and go to the Definitions page. For more information, see Chapter 6, "Searching for Test and Simulator Definitions."
Callback URL	If you are creating a simulator with a Service Type of Asynchronous two way, enter the URL of the web service that should be called back by the simulator.
SOAP Action	If you are creating a simulator with a Service Type of Asynchronous two way, enter the operation of the callback URL.
Delay (msec)	If you are creating a simulator with a Service Type of Asynchronous two way, enter the number of milliseconds that you want the simulator definition to wait before issuing the call back service invocation. If you are using this simulator along with an asynchronous two-way test definition, ensure that the Delay (msec) value you provide is less than the Time-out (msec) value defined for any test definition. For more information about the Time-out (msec) field, see Section 4.2, "How to Modify a Test Definition."

Test Messages

For more information about the elements in the Test Messages group box, see Section 5.1, "How to Create a Simulator Definition."

Prefix and Namespace Selection

Use the Prefix and Namespace Selection grid to define namespace data that will be used in the XPath values defined in the XPath Selection grid.

Available elements in the Prefix and Namespace Selection grid are discussed in Table 5-4.

Table 5-4 Prefix and Namespace Selection Grid Elements

Element	Description
Delete	Select one or more namespace rows and click Delete to execute the deletion. This button only appears when namespace rows are present.
Create	Click to manually add and populate a namespace row.
Prefix	Prefix that should be used for the namespace.
Namespace	Namespace to be used in the XPath data for the simulator definition.

XPath Selection

Use the XPath Selection grid to work with XPath values that are used to match the simulator definition with arriving requests. XPath values can also be used to validate data send in the test request. The values in this grid use the namespace values set in the Prefix and Namespace Selection grid.

Note:

If you are entering XPath values manually, it is important to maintain correlations with the values entered in the Prefix and Namespace Selection grid. Each XPath node must have a prefix that has been defined in the Prefix and Namespace Selection grid, unless it is an XPath expression.

Available elements in the XPath Selection grid are discussed in Table 5-5.

Table 5-5 XPath Selection Grid Elements

Element	Description
Delete	Select one or more XPath rows and click Delete to execute the deletion. This button only appears when XPath rows are present.
Create	Click to add and manually populate an XPath row.
XPath Sequence Id	Indicates the sequence of the XPath expressions. This value is required. This value is read-only when it has been generated using the Generate Xpath button.
Xpath	XPath value used to help match the simulator definition with arriving requests. These values can include XPath nodes and expressions. This value is read-only when it has been generated using the Generate Xpath button.
Is Node Key	Select if the XPath node is a key value to be used in matching arriving test requests with the simulator.
Condition	Select the condition you want to use: Is Valid: The value provided in the XPath field is valid and no Expected Node Value is supplied. Equals To: The value provided in the XPath field is valid and an Expected Node Value is supplied. Not Equal To Less Than Greater Than Less Than Equal Greater Than Equal Not Null
Expected Node Value	The value that the simulator expects to receive from the service that invokes it. When the simulator is actually executed, this value is compared with the actual value based on the validation condition selected in the Condition field When you use the Generate Xpath button to generate XPath data, this value may be populated, but can be modified as necessary. The Condition field value is used to qualify this value.

Simulator Instance Selection

Select the Simulator Instances tab to display the Simulator Instance Selection grid, which displays information about simulator instances generated using the simulator definition.

Available elements in the Simulator Instance Selection grid are discussed in Table 5-6.

Table 5-6 Simulator Instance Selection Grid

Element	Description
Refresh	Click to refresh the Modify Simulator Definition page.
Id	Click to display the selected instance ID on the Simulator Instances Detail page. For more information about the Simulator Instances Detail page, see Section 9.3, "How to View Simulator Instance Details."
Status	Displays the status of the simulator instance generated by the simulator definition. Initiated: The simulator instance has been initiated. Ended: This status is only applicable to simulator instances that do not involve validations. Indicates that the instance has ended. Faulted: The simulator instance could not execute properly due to exceptions or faults. Failed: The simulator instance did not pass validation. Passed: The simulator instance passed validation.
Start Date	Displays the date and time at which the simulator instance was initiated.
End Date	Displays the date and time at which the simulator instance ended.

Test Definition Selection

Select the Test Definitions tab to display the Linked Test Definition Selection grid, which displays information about test definitions associated with the simulator definition.

Available elements in the Linked Test Definition Selection grid are discussed in Table 5-7.

Table 5-7 Linked Test Definition Selection Grid

Element	Description
Delete	Select one or more test definition rows that you want to delete and click Delete to execute the deletion.
Assign	Click to access the Search Definitions - Test page, where you can search for a test definition to which you want to assign the simulator definition.
Refresh	Click to refresh the Modify Simulator Definition page.

5.3 How to Provide Multiple Request and Response Message Sets in a Single Simulator Definition

You can create a simulator definition that contains multiple pairs of request and response message data, as shown in Figure 5-8. This means that simulator definitions only need to be created per usage requirements, not per test data requirements.

Figure 5-8 Providing Multiple Request and Response Message Sets in a Single Simulator Definition

For example, if you want to simulate a service against five sets of test data, you can create a single simulator definition to simulate the service and include in it all five sets of test data with which you can the service to operate. This is as opposed to creating five separate simulator definitions, one per combination of service and set of test data.

When a simulator definition that includes multiple test data sets is invoked, the appropriate data set is matched for use based on key attributes identified in the request. At this point, the request validation and response provision can occur. Since we would typically use such definitions to handle several sets of data, it is recommended that you choose the same key values for every set of data.

Request Message Format

Use the format provided in Example 5-1 to include multiple sets of request data in the simulator definition.

The CAVSRequestInputs and CAVSRequestInput_1 envelopes are autogenerated upon the input of the endpoint URL value on the test definition. Use copy and paste commands to create more sets, such as CAVSRequestInput_2 and CAVSRequestInput_3.

Example 5-1 Request Message Format

<cavs:CAVSRequestInputs xmlns:cavs="http://schemas.xmlsoap.org/cavs/requestenvelope/">
<cavs:CAVSRequestInput_1>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:ns1="http://xmlns.oracle.com/SimpleProcess">
    <ns1:SimpleProcessProcessRequest>
. . .
    </ns1:SimpleProcessProcessRequest>
    </soap:Body>
</soap:Envelope>
</cavs:CAVSRequestInput_1>

<cavs:CAVSRequestInput_2>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:ns1="http://xmlns.oracle.com/SimpleProcess">
    <ns1:SimpleProcessProcessRequest>
. . .
    </ns1:SimpleProcessProcessRequest>
    </soap:Body>
</soap:Envelope>
</cavs:CAVSRequestInput_2>
</cavs:CAVSRequestInputs>

Response Message Format

Use the format shown in Example 5-2 to include multiple sets of response data in the simulator definition.

Example 5-2 Response Message Format

<cavs:CAVSResponseOutput_1>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:ns1="http://xmlns.oracle.com/SimpleProcess">
    <ns1:SimpleProcessProcessResponse>
. . .
    </ns1:SimpleProcessProcessResponse>
    </soap:Body>
</soap:Envelope>
</cavs:CAVSResponseOutput_1>

<cavs:CAVSResponseOutput_2>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:ns1="http://xmlns.oracle.com/SimpleProcess">
    <ns1:SimpleProcessProcessResponse>
. . .
    </ns1:SimpleProcessProcessResponse>
    </soap:Body>
</soap:Envelope>
</cavs:CAVSResponseOutput_2>
</cavs:CAVSResponseOutputs>

Envelope text is prepopulated. Enter actual message content within appropriate tags provided within the envelopes.

After entering request and response data sets and clicking the Generate Xpath button on the Modify Simulator Definition page, the XPath Selection grid provides access to available XPath values and enables you to select the XPaths that must be treated as key nodes.

For more information about the Modify Simulator Definition page, see Section 5.2, "How to Modify a Simulator Definition."

If your testing scenario includes test definitions, you can likewise create test definitions that contain multiple request and response message sets that work with the sets defined in your simulator definition.

For more information, see Section 4.3, "How to Provide Multiple Request and Response Message Sets in a Single Test Definition."

5.4 How to Create a Simulator Definition that Supports Chatty Services

You can create a simulator definition that can simulate multiple services, each with a different schema.

In general, we recommend that you create simulators that simulate a single specific service. However, in the case of chatty conversations, for the ease of maintenance, you may choose to simulate all callouts of an Application Business Connector Service (ABCS) using a single simulator definition.

Using this method, you have the advantage of using one simulator for a particular ABCS, regardless of the number of callouts that need to be made. This method also provides ease of maintenance because linked callouts can all be viewed and modified in one place.

For example, in some integration scenarios, participating applications do not provide services at the same level of granularity as operations in Enterprise Business Services (EBSs). In these scenarios, a requester ABCS may need to adopt patterns such as message enrichment, splitting, and aggregation and disaggregation as required by an EBS. Likewise, a provider ABCS may need to adopt patterns as required by participating application services.

These ABCSs, which are typically implemented using BPEL process, call out to several services. To test this chatty ABCS using CAVS, there will likely be a need to replace the services that the ABCS calls out to with several simulators. It will also be required that these multiple request/response simulators be correlated, so that they accurately emulate the transaction of the same entity.

When this type of simulator is called, CAVS initiates the following general flow:

1. Selects simulator definition.

2. Validates the first request message based on the selected simulator.

3. Returns the appropriate response message, if the selected simulator is a two-way simulator.

4. Repeats steps 2 and 3 until the chatty service conversation is complete.

Request Message Format

Use the format shown in Example 5-3 to create a simulator definition that supports chatty service conversations. This format provides the ability to specify a set of request and response messages, along with success criteria for each of them. This format is the same as that used for multiple requests and responses in a simulator definition. However, in this case, the schemas for each set will be different.

Example 5-3 Request Message Format

<cavs:CAVSRequestInputs xmlns:cavs="http://schemas.xmlsoap.org/cavs/requestenvelope/">
<cavs:CAVSRequestInput_1>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:ns1="http://xmlns.oracle.com/Service1">
    <ns1:Service1Request>
. . .
    </ns1: Service1Request>
    </soap:Body>
</soap:Envelope>
</cavs:CAVSRequestInput_1>

<cavs:CAVSRequestInput_2>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body xmlns:ns2="http://xmlns.oracle.com/Service2">
    <ns2: Service2Request>
. . .
    </ns2: Service2Request>
    </soap:Body>
</soap:Envelope>
</cavs:CAVSRequestInput_2>

After you have provided request and response messages, click the Generate Xpath button on the Modify Simulator Definition page to generate XPath values. Modify the generated XPath values, if necessary.

For more information about the Modify Simulator Definition page, see Section 5.2, "How to Modify a Simulator Definition."

When this type of simulator is called, separate simulator instances are created for each request and response pair. The evaluation of actual response versus expected response is handled per instance created for the same simulator definition.

5.5 How to Send Dynamic Responses in a Simulator Response

CAVS simulator definitions are actually predefined request and response message sets. In some cases, you may not know the values for all the fields in the request message. Additionally, you may want to send these unknown dynamic values in a response to the service that called the simulator.

For example, consider the Enterprise Business Message (EBM) ID. This value is normally generated on the fly by AIA services. If you create a simulator that talks to this AIA service, you do not have a way to validate the value in the EBM ID field of the request message because the value is dynamically generated.

You may to choose to avoid validations of this value by setting the CAVS XPath validation for the EBM ID field to isValid. However, you may have a requirement in which you need to send this dynamic value back in a particular field of the simulator response. To meet this requirement, you can let the simulator pick the particular field (such as EBM ID) in the request and send it back as a field in the response.

To send a dynamic response in a simulator response:

1. Map a field from the request message and add it to the response message. These are two valid formats you can use:

   • #@#XPATH.{copy the XPath from request msg Ex./soap:Envelop/soap:Body..}#@#

   • #@#SYSTEM.{SYSDATE}#@#

2. Before sending the response, the simulator will pick up this ID from the generated XPath, substitute the actual value, and send it in the response.

   The strings referenced above will form a part of the response message. To know what the request message XPath values are, use the output that was generated by clicking the Generate Xpath button.

   For example, let's say that the request SOAP message has the nodes shown in Example 5-4:

Example 5-4 Request SOAP Message Nodes

<corecom:PersonName> 
    <corecom:FirstName>CAVS</corecom:FirstName>
    <corecom:MiddleName>FP</corecom:MiddleName>
    <corecom:FamilyName>AIA</corecom:FamilyName>
    <corecom:CreationDateTime></corecom:CreationDateTime>
</corecom:PersonName>

You would define your response SOAP message as shown in Example 5-5:

Example 5-5 Response SOAP Message

<corecom:PersonName>
    <corecom:FirstName>#@#XPATH.{/soap:Envelope/soap:Body/corecom:CreateCustomerParty
    ListEBM/ebo:DataArea/ebo:CreateCustomerPartyList/
    corecomx:Contact/corecomx:PersonName/corecomx:FamilyName}#@#2dot1</corecom:FirstName>
    <corecom:MiddleName>#@#XPATH.{/soap:Envelope/soap:Body/corecom:CreateCustomerParty
ListEBM/ebo:DataArea/ebo:CreateCustomerPartyList/corecomx:Contact/corecomx:Person
Name/corecomx:MiddleName}#@#</corecom:MiddleName>
    <corecom:FamilyName>#@#XPATH.{/soap:Envelope/soap:Body/corecom:CreateCustomerParty
ListEBM/ebo:DataArea/ebo:CreateCustomerPartyList/corecomx:Contact/corecomx:Person
Name/corecomx:FirstName}#@#</corecom:FamilyName>
    <corecom:CreationDateTime>#@#SYSTEM.{SYSDATE}#@#</corecom:CreationDateTime>
</corecom:PersonName>

In this case, the response would be modified by the CAVS engine by copying values from the request as shown in Example 5-6.

Example 5-6 Response Message Modified by CAVS

<corecom:PersonName>
    <corecom:FirstName>AIA2dot1</corecom:FirstName>
    <corecom:MiddleName>FP</corecom:MiddleName>
    <corecom:FamilyName>CAVS</corecom:FamilyName>
    <corecom:CreationDateTime>2008-05-12T15:26:43+05:30</corecom:CreationDateTime>
</corecom:PersonName>

Note:

2dot1 is a static string that is always appended to the FamilyName value.