Goal & Purpose

Create your first SOA Composite - Hello World ! Process

 Start JDeveloper.  Left click Applications node in the Applications Navigator and select New Application, as shown

Create an Application named Training.

Give “Training” in Application name

Select a suitable location and select SOA Application in the Application Template

The wizard now prompts you to create a project.  Later, you can add more projects to this application.

Give the project name as HelloWorld

Select Composite template as Composite with BPEL Process.  This is a convenient shortcut to tell that the composite we want to create would contain one BPEL process.  As an alternative, we can choose Empty Composite here,  add add a BPEL

 component later.

Click on Finish

A new dialog opens up.  This is to configure the BPEL component that we are adding to our composite.

Give name as HelloWorld_BPEL

Select Template as Synchronous BPEL Template and click ok.

 Templates are pre-defined structures provided by Oracle.  Essentially, by using a template, a few activities shall come by default, so that you are saved of the mundane steps of adding those activities.  It’s even possible to create your own custom templates.  As of now, we select the predefined template for a synchronous process.  A synchronous process is one which is expected to be comparatively short-lived (few seconds to minutes) and hence can be expected to return a response quite quickly.  So, the client invoking a synchronous process can afford to wait (and block) for the response to come back.

The following structure comes up.

This is the picture of the composite (more technically, it’s the design time view of composite.xml).  As you can see, it contains a servicecomponent called HelloWorld_BPEL and a binding component called helloworld_bpel_client.

Service components are the building blocks that you use to construct a SOA composite application. Examples - BPEL, Human Task, Business Rules, Mediators, Spring.

Bindingcomponentestablish a connection between a SOA composite and the external world.  They are categorized as Service binding component and Reference binding components.  Service binding components provide the entry point to the composite Reference binding components provides access to the external service in the outside

world.  Examples include JCA Adapters (FTP adapter, DB adapter, Apps adapter etc), HTTP Binding, Direct binding etc.

Double click on this component to open it up.

As you can see, there is an input coming from the helloworld_bpel_client service binding  (which represents any client that is invoking our BPEL process).  

Drag an Assign activity from the component palette on the right.

In this assign activity, we can add any number of “Copy rules”.  Copy rules allow us to copy values from a source variable to a target variable, or to assign result of an expression (say a concatenate operation or a square root operation) to a target variable.

We want to create an expression similar to

“Hello” + Input = Output.   

This we shall create using the following steps:

Expand output variable so that you can see client:result.  This is the string field to which we want to assign some value.

From the icons on top right corner, drag an expression  onto client:result.

A dialog called Expression Builder opens up.  Expression builder is a nifty tool to quickly create expressions.  It shows categories of operations.  You choose a category and it shows you the expressions within that category.   For example

Here we choose “concat” function from the String Functions category

Click on Insert into expression.  This puts the concat() into the Expression box above.  (When you get experienced, you can simply write functions directly here.).  Place the mouse cursor between “(“ and “)” of the concat function

Next we expand the input and select the client:input field.  This is the field that has got the value that was sent by the user.  We want to append hello to this and assign that to the output variable.  So choose this

Press Insert into expression

Type ‘Hello’ followed by a comma.    Note that in BPEL, (or more precisely xpath) we use single quotes for strings

Now press OK.  Control returns to Edit Assign dialog.  Now expand the outputVariablein the To section (right section) and select client:result field.  Press OK

This has completed the Assign activity.  For better readability we should always give descriptive names to activities.  

So double click on the text “Assign1” (not the icon) and give name as “Assign_Hello”  

The BPEL process is now complete !

BPEL Persistence properties are used to control, when and how a process need to be dehydrated.

1. inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to true, Oracle BPEL Server keeps the instances of this process in memory only during the course of execution. This property can only be set to true for transient processes (process type does not incur any intermediate dehydration points during execution).

• false (default): instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.

• true: Oracle BPEL Process Manager keeps instances in memory only.

2. completionPersistPolicy

This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Console. This property is applicable to transient BPEL processes (process type does not incur any intermediate dehydration points during execution).

This property is only used when inMemoryOptimization is set to true.

This parameter strongly impacts the amount of data stored in the database (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput.

• on (default): The completed instance is saved normally.

• deferred: The completed instance is saved, but with a different thread and in another transaction, If a server fails, some instances may not be saved.

• faulted: Only the faulted instances are saved.

• off: No instances of this process are saved.

<component name="mySampleBPELComponent">
...
<property name="bpel.config.completionPersistPolicy">faulted</property>
<property name="bpel.config.inMemoryOptimization">true</property>
...
</component>

3. oneWayDeliveryPolicy

The oneWayDeliveryPolicy is from the Oracle 10g configuration property deliveryPersistencePolicy.The new configuration property name is bpel.config.oneWayDeliveryPolicy.

This property controls database persistence of messages entering Oracle BPEL Server. Its used when we need to have a sync-type call based on a one way operation. This is mainly used when we need to make an adapter synchronous to the BPEL Process.

By default, incoming requests are saved in the following delivery service database tables: dlv_message

• async.persist: Messages are persisted in the database.

• sync.cache: Messages are stored in memory.

• sync: Direct invocation occurs on the same thread.

--------------------------------------------------------------------------------------------------------------

#291 BPEL configuration properties

Rule of thumb for BPEL is - keep those processes short and sweet.
Transient, synchronous is the way to go, if possible.

ORCL docs provide for very good reading in this area - I recommend the FMW Developer Guide for SOA Suite, the FMW SOA Suite Administrators Guide as well as the FMW Performance Guide. The info below, has to a great extent, been taken from there. I also recommend AnTony Reynolds and Matt Wright's - Oracle SOA Suite 11g Developers Guide - available here

Tuning BPEL Engine Threads -

These are the guys who do the actual work -

The dspInvokeThreads property specifies the total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.


The dspEngineThreads property specifies the total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.

The dspSystemThreads property specifies the total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.

Start off with the defaults, and tune - if necessary - paying attention to the heuristics above.

These properties can be set in EM. 

As you can see, the Audit Level is set to Inherit as default. Please see my My Post on Logging for more info.

Here is the doc -

For production systems - use Production or Error - depending on your logging requirements.

Audit Detail threshold - under the threshold? - details store in the audit_trail table.
over the threshold? then audit info will be written to the audit_details table.

Large Doc Threshold - same concept -

This is the maximum size (in kilobytes) of a BPEL variable before it is stored in a separate location from the rest of the instance scope data.

Payload Validation - validates incoming and outgoing XML documents 
Incurs a performance hit.

Other Configuration properties

Now let's look at the rest -

As you can see, the descriptions shown in EM are useful and succinct.
You will not change most of these, however - some are worth investigating -


For one way invokes with possible callbacks -

Per default requests to execute a BPEL process are written to the soa_infra.dlv_message table - this causes a message to be generated that is then picked up by a worker thread which then starts executing the process.

Big benefit - Reliability no requests get lost - however we do have an extra DB write.

If set to async.cache then the request is cached in-memory - better Performance

If set to sync -> queuing is bypassed, and the BPEL process is invoked synchronously.
Client has full control of what happens.


1. bpel.config.oneWayDeliveryPolicy
Default value specified in MBean - accessible from em

async.persist: Messages are persisted in the database hash map.
sync.cache: Messages are stored in memory.
sync: Direct invocation occurs on the same thread.

Can be overwritten in the BPEL process definition in composite.xml -

onewayDeliveryPolicy=sync
and
transaction=required
BPEL process runs in the same thread and the same transaction.

onewayDeliveryPolicy=sync
and
transaction=requiresNew
BPEL process runs in the same thread but within a new transaction.

completionPersistPolicy

Here you need to ask yourself, whether the instance data needs to be persisted, and if so to what extent.
If your BPEL process integrates System A with System B. then the fact that the data has been successfully written to B suffices.

Simple example -

here is my one-way BPEL process that writes its input to a file -

Test - here is the output order.

Here is the em trace -

Now I set the the completePersistPolicy to off in composite.xml -
I also need to set inMemoryOptimization = true

Re-test - my output file has been written.

Check the audit trail in em -

Probably faulted would be the best setting here.

The SyncMaxWaitTime property sets the maximum time the process result receiver
waits for a result before returning. Results from asynchronous BPEL processes are
retrieved synchronously by a receiver that waits for a result from Oracle BPEL Server.
The default value is 45 seconds.

If you have sync BPEL processes and you see the need to up this property, then consider making the processes async.

MaxRecoverAttempt - number of times to attempt recovery of invoke/callback messages.

The recovery behavior for invoke and callback messages is different when
MaxRecoverAttempt is set. For example, assume MaxRecoverAttempt is set to 4.
■ Invoke message recovery is retried 4 (N) times before moving the message to
the exhausted state.
■ Callback message recovery is retried 5 times (N + 1) before moving the
message to the exhausted state.
This is the expected behavior. The first attempt is not counted as a recovery
attempt. The recovery attempts are incremented by the BPEL process service
engine. If MaxRecoverAttempt is set to 1, you see one default resolution process
and then one recovery attempt.

Recovery Configuration

This feature is detailed in the Administrator’s Guide for Oracle SOA Suite and Oracle
Business Process Management Suite


e.g. We are trying to update a DB and it is temporarily unavailable.

This covers -
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

When should auto-recovery be available?
Check out the RecurringScheduleConfig - set start/stopWindowTime

Check out StartupScheduleConfig -
the default config tells us -

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. 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.

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.

 

Partner Link Properties

The main ones ares -

nonBlockingInvoke=true
PartnerLink Service will executed in a separate transaction.

idempotent=false
Executes on same Thread/transaction

 

JBoss Commnunity 에서 다운로드 한 JBoss 기본 로깅 레벨은 DEBUG 입니다.

구동 시간도 오래 걸리고 로그 메시지도 DEBUG가 추가되므로 보기 힘듭으로 JBoss 설치 후 반드시 기본 로깅 레벨 변경이 필요

<JBOSS_HOME>/server/<CONFIGURATION>/conf/jboss-log4j.xml 파일을 편집기로 열어서 보면 JBoss 5부터 Threshold가 추가되어 있는데 이 옵션의 실제 기본값은 DEBUG 입니다. 따라서 이 값을 변경해주면 기본 로깅 레벨을 변경할 수 있습니다.

※ 참고사이트 : http://cafe.naver.com/jbossug/1327