SOA 11g SOA Infra DB states for SOA Composites and Components

I found this extremely useful list of states for SOA 11g composites and various components in the SOA INFRA DB which we have benefited greatly in various engagements, so I thought it was worth sharing with you all.

 

COMPOSITE_INSTANCE States

State	Description
0	Running
1	Completed
2	Running with faults
3	Completed with faults
4	Running with recovery required
5	Completed with recovery required
6	Running with faults and recovery required
7	Completed with faults and recovery required
8	Running with suspended
9	Completed with suspended
10	Running with faults and suspended
11	Completed with faults and suspended
12	Running with recovery required and suspended
13	Completed with recovery required and suspended
14	Running with faults, recovery required, and suspended
15	Completed with faults, recovery required, and suspended
16	Running with terminated
17	Completed with terminated
18	Running with faults and terminated
19	Completed with faults and terminated
20	Running with recovery required and terminated
21	Completed with recovery required and terminated
22	Running with faults, recovery required, and terminated
23	Completed with faults, recovery required, and terminated
24	Running with suspended and terminated
25	Completed with suspended and terminated
26	Running with faulted, suspended, and terminated
27	Completed with faulted, suspended, and terminated
28	Running with recovery required, suspended, and terminated
29	Completed with recovery required, suspended, and terminated
30	Running with faulted, recovery required, suspended, and terminated
31	Completed with faulted, recovery required, suspended, and terminated
32	Unknown
64	-

Any value in the range of 32 to 63 indicates that the composite instance state has not been enabled, but the instance state is updated for faults, aborts, etc.

CUBE_INSTANCE States

State	Description
0	STATE_INITIATED
1	STATE_OPEN_RUNNING
2	STATE_OPEN_SUSPENDED
3	STATE_OPEN_FAULTED
4	STATE_CLOSED_PENDING_CANCEL
5	STATE_CLOSED_COMPLETED
6	STATE_CLOSED_FAULTED
7	STATE_CLOSED_CANCELLED
8	STATE_CLOSED_ABORTED
9	STATE_CLOSED_STALE
10	STATE_CLOSED_ROLLED_BACK

 

MEDIATOR_INSTANCE

STATE	Description
0	No faults but there still might be running instances
1	At least one case is aborted by user
2	At least one case is faulted (non-recoverable)
3	At least one case is faulted and one case is aborted
4	At least one case is in recovery required state
5	At least one case is in recovery required state and at least one is aborted
6	At least one case is in recovery required state and at least one is faulted
7	At least one case is in recovery required state, one faulted and one aborted
>=8 and < 16	Running
>= 16	Stale

 

Referenced from https://blogs.oracle.com/dasoa/entry/list_of_all_states_from

 

 

Duplicate instances when using DB adapter in high availability environment.

Many a times I have noticed that when you use DB Adapters (SOA Suite 11g) for integrating with applications like the E Business Suite in a clustered high availability environment, at times there will be multiple instances for the same request.

The number of instances each entry in the DB would generate would directly correlate to the number of nodes on a cluster.

Such that if there are 3 nodes on the soa cluster then the polling composite deployed on each of the managed servers would be attempting to process this file and you would end up with extra instances of the composite which would result in errors or processing the item multiple times depending on the business process.

There are 2 different solutions for this problem on the blogs and you can chose anyone depending on which one suits your particular scenario.

However I prefer the quick an easy one to use the singleton property of the JCA DB adapter .

Ideally you would want to do this from the source in the composite.xml

There’s a property of Inbound endpoint lifecycle support within Adapters called Singleton.
To enable this feature for high availability environment for a given inbound adapter endpoint, one must add the singleton JCA service binding property in the composite.xml within the <binding.jca> element and set it to a value of true as shows.

Singleton Property in composite.xml

    <binding.jca config="bindin_file.jca">
        <property name="singleton">true</property>
    </binding.jca>

More details about this are available @

http://docs.oracle.com/cd/E23943_01/integration.1111/e10231/life_cycle.htm#BABDAFBH

Runtime Fix

However on an already deployed composite you can go composite dashboard and open the properties tab for the db adapter component from the EM console and add a new property
you will see ‘singleton’ in that list and we can set it to ‘true’

Click Apply and Save.

This should result in the following row in your composite.xml which you can check from the xml definition in the composite dashboard.

<property  name="singleton"  type="xs:boolean"  many="false"  source="PollNYSolutionsJobsEBizReqABCS_ptt:receive[hdr]">true</property>

which is the equivalent of the change in the source code, Obviously you will lose this change if a subsequent deployment happens so make sure this is replicated to the source code as well.

The same can be achieved in OSB using by editing the Configuration Details of the proxy service and set ‘Topic Message Distribution’ to ‘One Copy Per Application’.

Refs:

http://javaoraclesoa.blogspot.co.uk/2012/04/polling-with-dbadapter-in-clustered.html

http://ayshaabbas.blogspot.co.uk/2012/11/db-adapter-singleton-behaviour-in-high.html

SOA 11g Composite states and behavior

Useful composite states and the behaviour for reference.

Composites Table

The Composites table enables you to manage the state of a selected SOA composite application. All actions in this table, except Deploy, require you to select a row in the table.

Element	Description
Shut Down	Shuts down a running SOA composite application revision. Any request (initiating or a callback) to the composite is rejected if the composite is shut down.Note: The behavior differs based on which binding component is used. For example, if it is a web service request, it is rejected back to the caller. A JCA adapter binding component may do something else in this case (for example, put the request in a rejected table). This option displays when the composite application has been started.
Start Up	Restarts a composite application revision that was shut down. This action enables new requests to be processed (and not be rejected). No recovery of messages occurs.This option displays when the composite application has been stopped.
Retire	Retires the selected composite revision. If the process life cycle is retired, you cannot create a new instance. Existing instances are allowed to complete normally.An initiating request to the composite application is rejected back to the client. The behavior of different binding components during rejection is the same as described above for the shut down option. A callback to an already-initiated composite application instance is delivered properly. This option displays when the composite application is active.
Activate	Activates the retired composite application revision. Note the following behavior with this option: All composite applications are automatically active when deployed. Other revisions of a newly deployed composite application remain active (that is, they are not automatically retired). If you want, you must explicitly retire them. This option displays when the composite application is retired.
Set As Default	Sets the selected composite application revision to be the default. Default revisions are indicated by a green dot in the Composites table. If a new request comes in for a specific composite application revision, that composite application revision is invoked. If a new request comes in without specifying a revision, the default revision is invoked. The default revision does not change when a composite application is retired. The default revision is changed automatically when a default composite application revision is undeployed.The default composite revision also changes automatically when you redeploy a composite. The newly redeployed revision automatically becomes the default revision, unless at the time of redeployment you specify to keep the previous default revision unchanged. Note that inbound adapters are only activated on the default revision.
Deploy	Deploys a revision. Deployment activates the composite application in the SOA Infrastructure. Use this selection when you want to deploy: A new SOA composite application for the first time A new revision (for example, 2.0) of a SOA composite application that already has a different revision that is currently deployed (for example, 1.0). This option enables both revisions 1.0 and 2.0 to be deployed at the same time. If you specify a revision that already exists, you receive an error and must use either a different revision or perform a redeployment to overwrite the existing revision.
Undeploy	Undeploys the selected composite application revision. The consequences of this action are as follows: You can no longer configure and monitor this revision of the composite application. You can no longer process instances of this revision of the composite application. You cannot view previously completed processes. The state of currently running instances is changed to stale and no new messages sent to this composite are processed. If you undeploy the default revision of the composite application (for example, 2.0), the next available revision of the composite application becomes the default (for example, 1.0).
Redeploy	Redeploys an existing revision of a SOA composite application. The consequences of this action are as follows: A new version of a revision of a currently deployed SOA composite application is redeployed (for example, old version 1.0 is redeployed as new version 1.0). The older, currently-deployed version of this revision is removed (overwritten). If the older, currently-deployed version of this revision has running instances, the state of those instances is changed to stale.
Composite	Displays the deployed SOA composite application name. Click a specific revision to access its home page. A green dot indicates a default SOA composite application revision.Note: You occasionally see a red error icon before a composite name. The tool tip says Target not found. If you click the icon, you get an error stating that the composite application revision is not available. This can occur because either the composite has been undeployed or the SOA Infrastructure has not yet loaded this composite application.
Partition	Displays the partition in which the SOA composite application is deployed. To bulk manage the deployment life cycle of large numbers of composites, use the Partition Home page and the Manage Partitions page. You create and delete partitions from the Manage Partitions page, which you access from the SOA Infrastructure target menu.A partition is required before you can deploy any composites. If a partition is deleted, this automatically undeploys all SOA composite revisions in the partition.
Status	Displays the status of the SOA composite application (either Up (on) or Down (off)).
Mode	Displays the mode of the SOA composite application (either active or retired).
Instances	Displays the number of instances for each SOA composite application revision.
Faulted Instances	Displays the total number of faults in all instances of this revision of the SOA composite application. Each instance can have more than one fault.
Last Modified Date	Displays the time at which the SOA composite application was deployed, redeployed, or reconfigured.