Sunteți pe pagina 1din 2

BPEL Service Engine Cheat Sheet

BPEL Service Engine Architecture


 Does not use the init() method

Message Flow – post()


 Receives NormalizedMessage from Fabric
 Uses InvocationContext to retrieve Composite, Wire/Target
 DN+Operation to validate process/operation exists
 Calls Delivery layer, which retrieves the process
 Target URI specifies new or continue operation
 Persists via Delivery Persistence Manager to DLV_MESSAGE
 Message sent to Dispatcher layer with invokeMessage()
 Caller thread returns

Message Flow – request()


 Receives NormalizedMessage from Fabric, with Delivery layer retrieving the process as in post()
 Message sent to Dispatcher layer with scheduleLocal() – there is no persistence
 Caller thread continues to the Cube execution engine with outbound invocations delegated back to Fabric

Delivery Layer
Message Flow – post()
Uses Delivery Persistence Manager to persist messages to DLV_MESSAGE table with state=0. Documents exceeding threshold persisted in XML_DOCUMENT.
DLV_MESSAGE States: 0=Received, 1=Callback Resolved, 2=Performed/Handled
 Invokes Dispather addMessage()for batch messages otherwise invokeMessage() for post()

Message Flow – request()


Invokes Dispather scheduleLocal() without any persistence
Waits for results using DeliveryService.getResult() – this is a blocking call, other threads can set a result and unlock it. A BPEL Reply activity will
do a setResult(). There can be more activities after the Reply.
A sync BPEL process with an async wait() will cause this to block till syncMaxWaitTime is exceeded (45 seconds).

Dispatcher Layer
Queues and Thread Pools
Queue Thread Pool BPEL Configuration Setting Notes
Invoke Invoker thread pool dsp_invoke_threads
Callback Engine thread pool dsp_engine_threads Callbacks, resolve subscriptions, deploy/undeploy
System System thread pool dsp_system_threads Deprecated

Message Flow
Component Method Step Database Table Affected
Dispatcher InvokeMessage() New Invoker thread InvokeMessageHandler picks
scheduleLocal() message for post(), same client thread executes
using Invoke instance message for a sync request()
InvokeMessageHandler createInstance() Gets Cube process, finds and activates root scope DLV_MESSAGE.state=2
openRootScope()
InvokeMessageHandler manageScope() Digs into scope and opens Work Items
InvokeMessageHandler handlePerform() Creates the WorkManagerPerformer (WMP)
handleWorkItem() WMP.activate() Activates first work item (or multiple for Flow)
handleWorkItem() WMP.perform() Gets first work item and executes the activity CUBE_INSTANCE entry created
CUBE_SCOPE entry created:root scope
handleWorkItem() WMP.finalize() Opens token for next activity and resets activity i.e. CUBE_INSTANCE.state=closed.complete
no stack depth increase

WORK_ITEM table is not touched as there is nothing to retry or nothing faulted.

BPEL Process
 XML Specification of a business process with three key components: Scopes, Activities, Transitions
 Compiled down to Java into a Cube Runtime Map – this is a configuration map that specifies activities and relationships – not executable
 BPEL process is manifested by .bpel, .wsdl and .xsd files – the WSDL specifies PartnerLink Role for use in asynchronous interactions
Page 2

BPEL Process Schema Interactions


Table Name Notes
CUBE_INSTANCE For each BPEL process instance an entry is created in the table. This table contains information like creation date,
current state, title, process identifier and the last update date. Relationship between parent and child instances in
fields: cikey, parent_id, root_id. State values are: 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
CUBE_SCOPE Stores the scope data for an instance for example, all variables, payloads declared in the BPEL flow and some internal
objects that help route logic throughout the flow. It serializes the scope and stores it.
DLV_MESSAGE Delivery service message table. Invoke and Callback messages are stored here. Stores messages upon receipt. The
delivery layer will then attempt to correlate the message with the receiving instance. Initial message received is an
invoke message and mid process receive is a callback. DLV_TYPE values: 1: Invoke, 2: Callback. State values are:
0: STATE_UNRESOLVED, MESSAGE HAS BEEN RECEIVED FROM PARTNER BUT NOT PROCESSED, 1:
STATE_RESOLVED (But not delivered. Deprecated since PS5), 2: STATE_HANDLED, MESSAGE HAS
BEEN DELIVERED TO AN INSTANCE OR NEW INSTANCE CREATED, 3: STATE_CANCELLED, MESSAGE WAS
CANCELLED DUE TO SOME REASON, 4: STATE_MAX_RECOVERED, MAXIMUM NUMBER OF ATTEMPTS TO REOVER
MESSAGE HAVE ALREADY BEEN ATTEMPTED
DLV_AGGREGATION (PS5+) Used to identity if a message needs to be routed to create a new instance or continue an existing instance.
DLV_SUSCRIPTION Stores delivery subscriptions for an instance. Whenever an instance expects a message from a partner (for example,
the <receive> or <onMessage> activity) a subscription is written out for that specific receive activity. A callback can be
received only if there is the corresponding subscriber row exists in the database. BPEL is a conversation based system,
so a callback can be processed if a subscriber row exists in the dB. A BPEL instance must be waiting for a callback to be
processed, otherwise the callback (DLV_MESSAGE) stays in state=0. Once a callback is handled, this matching
subscriber moves to state=2. If scope has multiple subscriptions (such as pick with multiple onmessage) and only one
subscription is handled, other subscriptions in that scope move to state = 3. State values are: 0:
STATE_UNRESOLVED, 1: STATE_RESOLVED, 2: STATE_HANDLED, 3: STATE_CANCELLED
WORK_ITEM This table maintains BPEL instance activity state information. State values are: 0: Inactive, 1: Open Active, 2:
Open Suspended, 3: Open Pending Complete, 4: Open Faulted, 5: Closed Completed, 6: Closed
Finalized, 7: Closed Pending Cancel, 8: Closed Cancelled, 9: Closed Faulted, 10: Closed
Aborted, 11: Closed Compensated, 12: Closed Stale, 13: Open Pending Recovery
WI_FAULT Stores information about the faults, if there is any.
DOCUMENT_DLV_MESSAGE_REF DLV_MESSAGE references to XML_DOCUMENT are stored here.
HEADERS_PROPERTIES Store header properties for a message.
AUDIT_COUNTER This is used for async audit. The default auditStorePolicy for a system is sync, however, users may choose to set this
policy to async. In this case this table is used for the count of audit message batch before writing to database.
AUDIT_DETAILS Stores details for AUDIT_TRAIL events that are large in size. Details that are smaller than a specific size are stored inline
with the events in the AUDIT_TRAIL table.
AUDIT_TRIAL Stores record of actions taken on an instance (application, system, administrative and errors), and stores the audit trail
for BPEL instances. The audit trail viewed from the console is modeled from an XML document. As the instance is
worked, each activity writes out events to the audit trail as XML that is compresses and stored in a raw column.
Cube Engine
Model
Cube Engine is a language agnostic runtime engine that operates on runtime Cube Models, a runtime Java object model consisting of Blocks and Nodes.
Node is an atomic element and basic unit of execution e.g. Invoke, Receive, Assign activities.
Block is a composite execution unit and can contain other nodes and blocks e.g. Scope, Flow activities.
Cube Map is a set of blocks and nodes for a given language – it is the metadata for the Cube Engine.

Execution
WorkItem is a runtime instance of a Node.
Scope is a runtime instance of a Block.
WorkPerformer performs the execution logic of a Node.
WorkManager manages the lifecycle of a Node.
CubeInstance is the instantiation of a Process – it contains the scope activation tree and each scope contains the state of the variables.

Methods
Node: canActivate(), activate(), finalize()
Block: until(), handleException(), canActivate(), activate()
WorkItem: expire(), extend(), suspend(), resume()

oracle.com/SOA blogs.oracle.com/SOA @OracleSOA OracleSOA Oracle SOA© 2013 Oracle Corporation. All rights reserved.

S-ar putea să vă placă și