SOA Suite 12.2.1 Quick Look at Integration Workload Statistics

SOA Suite 12.2.1 Integration Workload Statistics

SOA Suite 12.2.1 has a new feature called Integration Workload Statistics for troubleshooting and monitoring SOA composites. It provides a performance graph and a chart for the average throughput time for the synchronous and asynchronous messages. It can provide details around the endpoints which might be causing delays, or bpel process activities which is taking up most of the execution time. There are five levels at which the data can be collected.

OFF	No data is collected. Default.
MINIMUM	System-wide resource usage data. Resource Utilization Metrics Only
BASIC	MINIMUM + Service and reference endpoint statistics, BPEL and EDN backup queue statistics, BPEL instance statistics.
Normal	BASIC + Key BPEL activities like Receive, Invoke, Pick, and onMessage
FINEST	NORMAL + Data on all BPEL activities.

At the finest level it gives details around all the BPEL activities (assign, transform pick invoke etc.), this details can be downloaded in the form of an excel sheet and analyzed offline.

The report can be downloaded in the form of a csv, html or pdf. It has details around system resources like JVM, system load, data-sources, work managers; composite statistics like composite endpoint performance details, internal queues and EDN queue. It also contains the top 25 slowest composite inbound and outbound endpoints, wires , backups in internal queues , top 25 slowest running process and top 25 most time consuming BPEL activities.

By default this feature is off. Following are the steps to enable it.

• Login to EM console. Navigate to SOA_INFRA->Monitoring->IWS Reports.
  
  
  
  
  
• Set the time and Click configure on top right hand corner.
  
• Set the level and time interval from the dropdown.
  
• Click on OK and we are all done.

I then tested few of my composites (synchronous and asynchronous both) and below is how chart was populated. It shows the throughput and the average response time in milliseconds for the synchronous and asynchronous process.

1. We can switch to a table view which looks like below. 
   
2. It also gives details around total number of synchronous and asynchronous messages, average throughput and total processing time
   
3. The details around average request processing time for synchronous and asynchronous processes, active requests  and requests processed for each of the engines i.e BPEL, Mediator, human workflow, business rules and spring engine can also be viewed. 
   
4. The reports can be downloaded by using links on the top right hand corner of the page.  
   
5. I downloaded a csv report at the finest level and below are some of the screen shots. Details around system resources can be seen below. 
   
6. Details around composite statistics. 
   
7. Details around slowest composite endpoint top 25 only. 
   
8. Details around backups in internal queues.
   
    
9. Details around longest running business processes and most time consuming activities top 25 only. 
   

Continue reading at Oracle DOC

SOA 12.2.1 Quick look at Using In-Memory SOA to Improve System Performance

From this release SOA supports use of Coherence cache for persisting BPEL instances ,, as compared to database. This feature is controlled by using the property bpel.config.completionPersistPolicy for the process. The values for this property is immediate, deferred and faulted. This property specifies when the bpel instance can be moved to database from coherence cache. Immediate as the name suggests means the instance will not be stored in memory at all, deferred implies that the instance will be persisted later, by a background thread which runs at an interval of  5 minutes by default and faulted means only faulted instances will be persisted.
Read more here.Oracle Guide

Please note that in earlier releases we had a similar feature but the difference was when the instance was not saved in memory at all. We could decide when the instance details could be saved to database and how it could be saved. Also it was only applicable for transient process and was used in conjuction with inmemoryoptimization.

·         completionPersistLevel BPEL Property : This property controls the type and amount of data persisted after instance completion. By Default, all state (including variable values) are saved; this property can be set to save only instance metadata information. This property is valid only for Transient Processes.

Note: This property is used only when the inMemoryOptimization is set to true.

Values:

-          all (default): Oracle BPEL saves the complete instance, including the final variable values, work item data and audit data.

-          instanceheader: Oracle BPEL manager saves only the instance metadata.

Impact:

Ø  This property can greatly impact the database growth.

Ø  It can also impact the throughput (due to reduced I/O)

·         completionPersistPolicy BPEL Property :This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Control. This property is applicable to transient BPEL processes.

Note: This property is used only when the inMemoryOptimization is set to true.

Values:

-          on (default): Completed instances are saved normally.

-          deferred: Completed instances are saved in a difference thread and in a different transaction. If a server fails, some instances may not be saved.

-          Faulted:  Only faulted instances are saved.

-          Off: No instances (and their data) are saved.

Impact:

Ø  This property can greatly impact the database growth.

Ø  It can also impact the throughput (due to reduced I/O)

Following is an easy way to test the use of memory persistence in SOA Suite 12.2.1.

1. Create a simple BPEL process. When creating the process choose the property deferred in the in memory SOA . 
   
2. Notice that the source of composite.xml has the property listed under the bpel process.
   
3. My bpel process just concats the input with hello and returns back the output.
4. Before deploying this process we need to set the inMemoryEnvironment property to true from em console. Navigate to SOA-Infra->Administration->Common Properties->More SOA Infra advanced property.
   
   
   
   
   
5. Deploy this BPEL process and Test it from SOAP-UI. Note that instance id is generated immediately but the instance is not available in the EM console. I fired the instance at approximately 9:00 PM. InstanceId is 30030.
   
6. Checked the EM console and the instance was not available after two minutes.
   
7. The instance was available after 5 minutes at 9:05 PM.
   

Hence we see that the process is being persisted in the DB after a five minutes of interval , helping to increase the performance.

SOA 12.2.1- Step by Step Instruction for Patching Running Instances of a Sample SOA Composite

Oracle SOA Suite 12c (12.2.1) supports Composite Instance Patching, which helps us to patch running instances of a composite and recover faulted instances after patching the runtime. Not all type of fixes are possible in a patch. In Jdeveloper the SOA Patch role is to be used for creating patches. Then wlst is used to deploying the patches.

I tried to create a sample BPEL process for testing the composite patching and below is outline and steps for the same. I created a simple BPEL process which sleeps for two minutes and then adds 5 to it. We will then patch it to add 55 to the input number. During the patching process there was a BPEL Instance in running state, once the patching was completed the BPEL process picked up the latest transformation.

Please note that for this Sample the integrated WebLogic domain will not work because the DB for MDS in this domain does not support versioning. I used XE database.

1. Create a simple BPEL Process. In my case a one way process which sleeps for five minutes and then adds 5 to the input.
   
   
   
   
2. Input = 6 and 5 was added to it. Output = 11
   
3. Steps to create a PATCH. Switch to the Role SOA Patch Developer as shown below.
   
4. This opens up the composite in the SOA Patch mode as shown below. See top right corner
   
5. Open the BPEL process. The only activity which we can edit is a transformation in this case. The other activities like WAIT was like disabled state. This helps us in deciding what components can be edited.
   
6. Open the transformation process and edit it
   
7. Edit the transformation to add 55 to the input number.Save the transformation
   
8. A patch file is then created at $Application-Home/$ProjectName/SOA/SCA-INF. This file has the information about the changed resource.
   
    
9. File Contents
   
10. Next we need to create the PATCH jar file. Right click on the project and choose deploy to SAR file. Deploy to Server will not work. For deploying we need to use WLST.
    
11. We need to validate the patch now using wlst. Run the wlst.cmd from $MW_HOME/oracle_common/common/bin
    
12. Validate the patch using the command. sca_validatePatch('http://localhost:23001','weblogic','weblogic1','C:\JDeveloper\mywork\SOAPatchSetSampleApplication\SamplePatchSetProject\deploy\sca_SamplePatchSetProject_patch.jar')
    
13. When the patch was being deployed a process was in running state. The input for this was 45
    
14. Deploy the Patch Jar file using the command. sca_patchComposite('http://localhost:23001','weblogic','weblogic1','C:\JDeveloper\mywork\SOAPatchSetSampleApplication\SamplePatchSetProject\deploy\sca_SamplePatchSetProject_patch.jar'
    
    
    
    
15. When the process completed it added 55 to the input as per the new transformation
    
16. All the new instances would also take the new transformation.
17. In case you want to go back to the original project, come out of the patch mode you will need to delete the patch file. Choose delete the patch to work again on the project
    
18. Patch Deleted
    
19. Read more at Oracle SOA 12.2.1 Docs