How to create AIA CAVS Simulator

AIA CAVS SIMULATOR CREATION 

Composite Application Validation System (CAVS) is part of the Application Integration Architecture Foundation Pack and with CAVS you can test your SOA Composites like SOAPUI or the SOA Test Suite.

Click “GO” in Composite Application Validation System.

1. Under Definitions, Click on Create Simulator.

2. Enter the Name of the Simulator(can be anything)

3. Paste the Complete SOAP- envelope request Message (which will be expecting from the Business Service(OSB)/Invoke Activity(BPEL) inside “<cavs:CAVSRequestInput_1>” .

4. Paste the Expected response below(Mock Response) inside “<cavs:CAVSResponseOutput_1> “.

And Click “Save and Next”.

5. In the Next page Click on Generate Xpath.

 6. After that we will be able to see Xpath Selection below the Expected Response Message.

Select any one as “Node Key”and Click “Save And Return”.
Once we Hit the CAVS from our Business Service, the Xpath will be compared with the Simulators and gives us the corresponding response.
Note : 
CAVS URL to Invoke from Business Service/AIAConfiguration :

http://Host:Port/AIAValidationSystemServlet/syncresponsesimulator

Its really easy to change from Stub(CAVS) to actual endpoint with redeployment.
Goto AIA console:- http://Host:Port/AIA

Click on AIA Configuration and enable/disable the checkbox. Then click on "Reload".

Alert vs Log vs Report in OSB

We have 3 out-of-box options for reporting in OSB, below are the differences between them. We can choose one of them based on our requirement.

Log:

• One of the basics way of logging in the Oracle Service Bus is adding Log Action in every corner of your proxy service.

• Your Proxy service might look something like below,

When really debugging a service it’s usually a matter of “what goes in” and “what goes out” and where did my transformation go wrong. So instead of flooding your services with Log Actions, OSB gives an alternate option of enabling Execution tracing(You can find it on each service on the Operational Settings tab, called execution and message tracing).

• Once we enable the Execution Tracing, the log file will show the full content of MessageContextImpl in every step (stage, route, etc) of the service. The MessageContextImpl holds are the variables like $body, $operation, $inbound and $header you need. – Only Problem in this option is we will end up in logging everything in the server. – Extremely easy to configure but little difficult to track the message in server logs.- Performance impact will be there since all the data is written into one single log file.

Not my preferable option. Since its difficult to track what you want in huge flat file(Server log)

Alert:

• An alert action in a pipeline is configured to raise alerts when such predefined conditions are encountered.

• You can also configure email and JMS alert destinations to receive a notification of the alert, and send the details to the alert recipient in the form of payload.

• Pipeline alerting can also be used to detect errors in a message flow.

Report:

• Reports mainly used for Track/Monitor the inbound and outbound messages in the proxy services.

• We can add a Report action in our Request-Response pipeline of our service.

• The expression field holds the part we actually want to trace – Usually the $Body or Specific Content of the Body element.

• The Key Name is best used for your reference and let you easily search later on. Which is identical throughout all service calls in the business process. – Correlation Id or Specific element from the body which we can use for tracking during production.

• We will be able to query all messages in a process or match them based on below categories,

• Inbound Service Name (the name of the pipeline)

• Error Code

• Report Index (key/value pairs)

• Date-Time

My preference is to use "Report" since you have more control on monitoring the data.