How to find purgeable instances in SOA/BPM 12c by Derek Kam

 

clip_image002If you are familiar with SOA/BPM 11g purging, after you have upgraded/implemented SOA/BPM 12c, you will not be able to use most of the SQL for 11g to determine the purgeable instances.  This is because SOA/BPM 12c is no longer using composite_instance table for composite instance tracking.

In SOA/BPM 12c, a common component is used to track the state associated with a business flow and report audit information.  This design will reduce the instance tracking data generated and stored in the database, and improve purge performance by minimizing the number of tables that need to be accessed.  Component instance state will no longer be stored in individual table for instance tracking purpose, the overall flow state will be stored in SCA_FLOW_INSTANCE table.

In SCA_FLOW_INSTANCE table, the “active_component_instances” column keeps track of how many component instances are still in a running/active state. These are the instances in one of the following states:

  • RUNNING
  • SUSPENDED
  • MIGRATING
  • WAITING_ON_HUMAN_INTERVENTION

When the “active_component_instances” value reaches 0, this indicates that the Flow is no longer executing. There is another column called “recoverable_faults”, this column keeps track of how many faults can be recovered. This information together with the “active_component_instances” is used to determine whether the Flow can be purged or not.

The SCA_FLOW_ASSOC table is used to record the association between the original Flow that creates the BPEL component instance and the correlated Flow. The SCA_FLOW_ASSOC table is used by the purge logic to ensure that all correlated Flows are purged together when none of the flow is in an active state.

Another important thing to take note: if you create a SOAINFRA schema with LARGE database profile, all transactional tables will be created with range-partition. If you decide to run the SOA purging with the purge script either manually by running the stored procedure or by using auto purge function which can be configured in Oracle Enterprise Manager Fusion Middleware Control, you will need to set the purge_partitioned_component => true (default is false), otherwise the purge logic will skip all partitioned tables when the purge script run and no flow instance will be purged.  You will be able to find all the partition tables in your SOAINFRA schema by using the following SQL: ?select table_name from user_tables where partitioned = ‘YES’;

You can use the following sample PL/SQL to determine whether the SCA_FLOW_INSTANCE has been partitioned and the number of purgeable flow instances in your SOAINFRA schema. Please read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

Using OSB 12.1.3 Resequencer by Derek Kam

 

clip_image002Resequencer feature has been added to Oracle Service Bus 12c (12.1.3), it utilises the same resequencer engine as Oracle Mediator.  The objective of this feature is to provide you with the ability to resequence the incoming messages that arrive in random order and send them to the target services in an orderly manner.  In this blog, I will give you a bit more information about this new feature in OSB and how to debug if you encounter an issue.

As mentioned in the official doc, the resequencer doest not support any XML and any SOAP service type, you need to define a WSDL in order to use the resequencer feature in OSB, and this WSDL must be only one-way, and must not contain any response elements.

The OSB Resequencer Strategies work in the same manner as Oracle Mediator;  it supports Standard, FIFO and Best Effort.  The differences between the resequencer implementation in Oracle Mediator and OSB are the ways in which both dispatch the message.  In OSB, pipeline acts as a Resequencer component. User cannot configure resequencer at any other OSB component.  After resequencing, the ordered messages will be processed further in the pipeline.  As soon as the message is pushed to the resequencer, caller will get a successful response. Though resequencer is part of the pipeline configuration, it will be invoked just before the pipeline is invoked.

Just like the Oracle Mediator,  OSB Resequencer also relies on the database for processing messages.  The database tables are automatically created when you run the repository creation utility (RCU) while creating the OSB domain.  The JNDI name used by the OSB resequencer is jdbc/SOADataSource.  The tables used by the resequencer are shown below:

You can use the Enterprise Manager to configure the throughput for resequenced messages.  Following are the properties specific to OSB resequencer:

  • Resequencer Maximum Groups Locked : Maximum number of groups locked by Resequencer in each attempt it makes to obtain locks on the groups. Locks are obtained on the groups so that only one managed server node processes the group at a time.
  • Resequencer Locker Thread Sleep : The number of seconds the Resequencer would pause between each iteration to obtain locks on the groups.
  • Purge Completed Messages : Delete message after successful execution. The default value will be set as true.

Read the complete article here.

SOA & BPM Partner Community

For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki