Administering BPEL process engine

Oracle BPEL process engine is a container that provides standards for assembling, developing, and executing synchronous as well as asynchronous services into end-to-end business processes in the SOA Infrastructure. When the soa-infra application is started, it initializes the BPEL engine in a stateless manner and loads composites from the MDS repository. If the composite contains any BPEL components, it targets them to the BPEL engine. At runtime, the BPEL engine waits for requests from different channels, such as messaging sources, databases, web services, and so on, and uses a Dispatcher module that maintains an in-memory logical queue containing units of work to process the incoming messages from these binding components. The BPEL process engine saves the process execution state in the dehydration store through a persistence module based on Oracle TopLink and hence there is no in-memory state replication required. The audit framework` continuously audits the work being processed by storing process execution information in the database.

Oracle Enterprise Manager Fusion Middleware Control allows you to perform key administration tasks, such as monitoring instances, recovering from faults, manually recovering (BPEL) failed messages, and configuring properties for the BPEL Service Engine. It also provides useful statistics and performance monitoring metrics for the engine. Figure 7.27 shows a typical BPEL Engine landing page that can be accessed by navigating to SOA Infrastructure | Service Engines | BPEL. Note that the engine executes the OrderNotificationProcess and OrderProcessing components that are part of the OrderBookingComposite application. The service engine dashboards have changed in Oracle Enterprise Manager Fusion Middleware Control 12c. Instead of showing a view of all instances and faults, it only shows a summarized view of deployed components, statistics of the components, and recoverable instances. Key administration tasks performed from the BPEL service engine dashboard include:

  • Displaying of details such as component name, current status, and the composites they belong to via the Deployed Components tab.
  • Monitoring of active and pending requests, thread statistics, and request breakdown for all BPEL components running on the service engine via the Statistics tab.
  • Performing a bulk manual recovery of undelivered invokes or callback messages due to a transaction rollback in the process instance for asynchronous BPEL processes via the Recovery tab.

Let's have a look at the following screenshot:

Administering BPEL process engine

Figure 7.27: The administration dashboard for the BPEL Service Engine

Configuring BPEL service engine properties

The BPEL service engine is the heart of the Oracle SOA Suite infrastructure. The runtime behavior of the engine and the instances executing on it largely depend on its property configurations. It is therefore essential for administrators to understand their functions and be able to alter them when needed. Configuration properties such as audit level and audit trail threshold, automatic recovery for BPEL processes, master node recovery scheduling, automatic recovery attempts for invoke and callback messages, and callback message order preservation are all used by the BPEL process service engine during processing of BPEL process service components. These properties can be accessed and modified by navigating to soa-infra (soa_server1) | SOA Infrastructure | SOA Administration | BPEL Properties.

A few of the BPEL service engine properties are described in the following table:

Property

Category

Description

Audit Level

Logging and Auditing

This property controls the level of information collected by the instance tracking infrastructure. The different values for this property are:

  • Inherit: Same as the infrastructure level.
  • Off: No flow tracking and payload tracking is collected.
  • Minimal: Instance tracking information is logged without payloads.
  • Production: Instance and payload information is collected except for assign activities.
  • Development: Instance and payload information is collected without any restriction. This may impact performance and should be used for debugging purposes.

AuditDetailThreshold

Logging and Auditing

Defines the maximum size in bytes an audit trail details string can be before it is stored separately from the audit trail. If a details string is larger than the threshold it will not be immediately loaded when the audit trail is initially retrieved; a link will be displayed with the size of the details string.

AuditStorePolicy

Logging and Auditing

This is a very important flag that determines the audit store strategy as one of the following three:

  • syncSingleWrite: Audit data is stored synchronously when instance data is stored in the cube instance table using the same thread.
  • syncMultipleWrite: Audit data is stored synchronously when instance data is stored in the cube instance table using a different thread.
  • AsyncsyncSingleWrite: Audit data is stored asynchronously using an in-memory queue and pool of audit threads.

DisableSensors

BPEL Engine

This flag switches the call to the sensor framework. The default value is false.

ExpirationMaxRetry

Message Retry

This controls the maximum number of times a failed expiration call on activities such as wait/on Alarm is retried before failing. If the activity or instance the expiration call is targeting cannot be found, the call will be rescheduled.

ExpirationRetryDelay

Message Retry

This flag sets the delay between the expiration retries.

LargeDocumentThreshold

Dehydration

Large XML documents severely impact the performance of the BPEL server if they are constantly read in and written out during instance processing. This property controls the maximum size in bytes of a variable before it is stored in a separate location from the rest of the instance data.

MaximumNumberOfInvokeMessagesInCache

BPEL Engine Memory

This property specifies the number of invoke messages that can be kept in the in-memory cache. Once the engine hits this limit, messages are saved in the database and can be recovered using the recovery job. Setting this value to -1 will disable messages being saved to the database. Each invoke message takes about 300 bytes in memory.

MinBPELWait

Dehydration

This property specifies the minimum amount of time that the engine will wait for before involving instance dehydration. If the wait duration is set less than or equal to this value, BPEL engine will execute the subsequent activities in the same thread/transaction.

OneWayDeliveryPolicy

BPEL Engine Memory

This controls how the one-way invocation messages such as invokes and callbacks are delivered. The supported values are:

  • async.persist: Messages are persisted in the delivery service persistence store.
  • async.cache: Messages are kept only in memory in delivery service.
  • Sync: Messages are processed by the same thread synchronously.

QualityOfService

BPEL Engine Memory

This flag enables or disables the Coherence cache for the service engine. If the value is set to CacheEnabled the engine will use Coherence.

InstanceKeyBlockSize

BPEL Engine Memory

Instance IDs for instantiating instances are preallocated from the dehydration store and kept in memory. This property sets the size of the block of instance IDs to allocate from the dehydration store during each fetch.

SyncMaxWaitTime

BPEL Engine

The maximum time a request/response operation will take before it times out. The default is 45 seconds.

ExecuteCallbacksInOrder

BPEL Engine

In order to main transactional integrity across, there is often a need to ensure that the callback message execution order is preserved. Setting this property to true will force the engine to ensure callback messages are picked up in the order in which they were received by the BPEL process service engine for a given business flow instance. This setting impacts all SOA composite applications deployed on the BPEL engine.

RecoveryConfig

Message Recovery

The recovery configuration properties control automatic message recovery during server startup or within a predefined window.

RecurringMaxMessageRaiseSize

Message Recovery

This property defines the number of messages to recover during recurring recovery.

StartupMaxMessageRaiseSize

Message Recovery

This property defines the number of messages to recover during startup recovery.

MaxRecoverAttempt

Message Retry

This property specifies the maximum number of times an invoke or callback activity is attempted for recovery. Once the number of recovery attempts exceeds this count, it is marked as Exhausted.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.188.218.157