BPEL

Installing Oracle SOA Suite 12c


Hi All,

As you all know that the Oracle 12c is out now… this is the first Major release where oracle has now combined the Oracle Service Bus with the SOA Suite Install… and its apparently only a 30 min single installation…

So firstly download the soa suite  from http://download.oracle.com/otn/nt/middleware/12c/121300/fmw_12.1.3.0.0_soaqs_Disk1_1of1.zip

This contains

SOA Suite 12.1.3 Size: 2.97 GB, Check Sum: 1579850769

Note: The generic SOA Suite Quick Start Installer for developers is used on all platforms. It allows you to quickly install a development or evaluation environment on a single host computer. It includes Oracle BPEL Process ManagerOracle Human WorkflowOracle Business Rules, Oracle Mediator, Oracle Service BusTechnology Adapters Oracle Enterprise Scheduler, SOA Spring Component, Enterprise Manager Fusion Middleware Control, Oracle JDeveloper with SOA IDE extensions and an integrated WebLogic Server and Java DB.

You can see the official quick start guide at http://docs.oracle.com/middleware/1213/core/SOAQS/integrated.htm#BEIJCGGE

Few things to note are

It needs JDK 1.7 so I downloaded (64 Bit) that from http://download.oracle.com/otn-pub/java/jdk/7u60-b19/jdk-7u60-windows-i586.exe

Next Set your JAVA_HOME

SET JAVA_HOME=C:\Program Files (x86)\Java\jdk1.7.0_60

For Linux

JAVA_HOME=$HOME/top_level_folder_jdkversion
export JAVA_HOME

Now we are all set to go….Open Command Prompt.

 IMPORTANT: It needs you to run that in admin mode.

Search for cmd.exe in the Start menu. Right-click the cmd.exe and select Run as Administrator.

In the command prompt, use the Java executable from the JDK on your system. Your command may look like this:

%JAVA_HOME%\bin\java -jar fmw_12.1.3.0.0_soa_quickstart.jar I did this and got the error in the screenshot… soa8
Note by default windows installs to Program files location which has a space so I had to use “” with “JAVA_HOME” and then it fired just fine. C:\Nitin\SOA\SOA12c>”%JAVA_HOME%”\bin\java -jar fmw_12.1.3.0.0_soa_quickstart.jar

soa7

soa6

soa5

soa4

soa3

That’s it now it’s time to sit back and relax….

soa2

soa1

soa11

Once you hit finish it launches Jdeveloper for the first time… Prompts to select the role I chose the studio role and allowed to import preferences from my previous installs which is optional.

soa10

soa9


ALL DONE…. Happy Developing….

Please leave your feedback in comments.

Advertisements

Configuring Automatic Engine Recovery for Oracle BPEL Process Manager


Oracle SOA Suite provides an automatic recovery feature in Oracle Enterprise Manager Fusion Middleware Control Console that enables you to configure and recover:

  • All activities (for example, wait activities and OnAlarm branches of pick activities) that have an associated expiration date and are scheduled with the SOA Infrastructure to be rescheduled
  • All activities that are not complete over a provided threshold time
  • All invoke and callback messages that are unresolved

Engine Recovery

To configure automatic recovery:

  • In the navigator, right-click soa-infra and select SOA Administration > BPEL Properties.
  • Click More BPEL Configuration Properties.
  • In the Name column, click RecoveryConfig.
  • Expand RecurringScheduleConfig.

This section enables you to configure recurring recovery attempts.

  • Set the following properties to values appropriate to your environment, and click Apply.
  • Property Description
    maxMessageRaiseSize The maximum number of messages to submit for each recurring recovery attempt. Use this property to limit the impact of recovery on the server. Note that this value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.

    The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A 0 value causes no messages to be selected from the database (effectively disabling recovery).

    startWindowTime The start time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:009:00).

    The default value is midnight (00:00). Any invalid parsed time value is defaulted to midnight.

    stopWindowTime The stop time for the daily recovery window, specified in a 24-hour notation. Therefore, 2:00 pm is specified as 14:00. The leading zero does not need to be specified for single digit hour values (1:009:00).

    If you do not want daily recovery, set the start and stop window times to be the same value. If the stop window time is earlier than the start window time, both the start and stop window times are changed to their respective default values.

    The default value is midnight (04:00), effectively setting recurring recovery to run until 04:00.

    Any invalid parsed time values default to 00:00.

    subsequentTriggerDelay The number of seconds between recovery attempts during daily recurring startup recovery periods. If the next recovery trigger falls outside of the current recovery period, that trigger is not scheduled until the next recurring recovery period (tomorrow).

    The default value is 300 (five minutes). A negative value causes the default to be selected.

    threshHoldTimeInMinutes This is the threshold time in minutes to ignore for automatic recovery processing. For automatic invoke and callback recovery, this value is used for picking messages with a received date less than the threshhold time.

    For automatic activities recovery, this value is used for picking activities with a modification date less than the threshhold time.

    This property prevents the message contention scenario in which a BPEL process service engine picks up a message for recovery while another thread on the service engine is in the middle of processing the message. This property ensures that the recovery part of the service engine only attempts recovery on messages older than the value for threshHoldTimeInMinutes.

    The default value is 10 minutes. A negative value causes the default to be selected.

  • Expand StartupScheduleConfig.

This section enables you to configure server startup recovery attempts.

  • Set the following properties to values appropriate to your environment, and click Apply.
Property Description
maxMessageRaiseSize The maximum number of messages to submit for each startup recovery attempt. Use this property to limit the impact of recovery on the server. Note that this value specifies the maximum number of messages to filter from activity, invoke, and callback queries; that is, 50 messages from each of the activity, invoke, and callback tables.

The default value is 50. A negative value causes all messages selected from the database to be submitted for recovery. A zero value causes no messages to be selected from the database (effectively disabling recovery).

startupRecoveryDuration Specifies the number of seconds that the startup recovery period lasts. After the server starts, it goes into a startup recovery period. During this period, pending activities and undelivered callback and invocation messages are resubmitted for processing.

The default value is 600 (ten minutes). A negative or zero value disables startup recovery.

subsequentTriggerDelay The number of seconds between recovery attempts during the server startup recovery period. If the next recovery trigger falls outside the server startup period, that trigger is not scheduled and the server moves into the recurring recovery period.

The default value is 300 (five minutes). A negative value causes the default to be selected.

Note:

In a cluster, it is possible for different nodes to concurrently attempt an automatic recovery of the same items. The first node to lock the item attempts the recovery, while other nodes may raise an exception that can be safely ignored.

Running Mediator instances issue


We encountered an issue with one of our clients when the SOA Purge wasn’t being very effective due to the running mediator instances even though the rest of the flow trace had completed, This wasn’t an issue for business as such however in most cases caused them to fall out of the criteria for Purge due to the state in which these mediator instances were in.

This should not cause much of a problem to clients who have are low on volumes, however for any of the larger clients where the daily volumes runs into Millions this can be a big problem.

As always the first step to solving a problem lies in the identification of the root cause so we wrote the following query to identify any running Mediator instances when the composite itself has completed.

Query to be run on the SOA Infra DB (SOA 11g).

SELECT comp.*
FROM mediator_instance mi,
 composite_instance comp,
 cube_instance ci
WHERE mi.composite_instance_id = comp.id
AND mi.composite_creation_date > (sysdate - 12) -- select the number of days you want to run this for
AND comp.CREATED_TIME > (sysdate - 12) -- select the number of days you want to run this for
AND comp.state IN (1,3,9,11,17,19,21,23,25,27,29,31)
AND mi.component_state IN (1,2,8)
AND ci.cmpst_id = comp.id
AND ci.creation_date > (sysdate - 12)
AND ci.state IN (4,5,6,7,8,9,10)
ORDER BY comp.created_time;

For a list of what these states mean and stand for refer to my earlier post https://nitinaggarwal.wordpress.com/2013/06/12/soa-11g-soa-infra-db-states-for-soa-composites-and-components/

Once you have identified the various composites you can then look the details up using the EM or writing further DB queries.

In most cases the problems lies in the way the code is written and hence needs to be fixed.

In certain scenarios we noticed that if for instance a Bpel calls a mediator (sequentially) and there is a fault in that mediator calling a reference.

Due to the fault policies the bpel would re try as configured which would then initiate another call to the mediator and might recover in this case if the root cause is resolved.

As a result of the above the composite will be marked as completed however that did not update the status of the mediator instances and left them either running or one of the other non purgeable states.

There isn’t much you can do in this scenario as with SOA 11.1.1.4 there isn’t an option to abort specific components and you can’t abort a composite which is already completed.

Having speaking to my contacts I found out that there is another similar bug in SOA 11.1.1.7 product and a fix will be made available as part of early patches to the 11.1.1.7 release.

One work around for such a scenario is to Un-deploy or Re-deploy the composite which will mark all the instances as stale and thus make them eligible for purging.

For most other cases we implemented some code changes that got rid off any such occurrences.

Also implemented a lot of performance tuning changes to the engine settings which helped us a lot, but the details for those will come in a later post.