Dispatcher System Threads BPEL Threading Model

Oracle BPEL Process Manager Performance Tuning 13-7

13.3.2.1 idempotent

An idempotent activity is an activity that can be retried for example, an assign activity or an invoke activity. Oracle BPEL Server saves the instance after a nonidempotent activity. This property is applicable to both durable and transient processes. Values: This property has the following values: ■ False: Activity is dehydrated immediately after execution and recorded in the dehydration store. When idempotent is set to False, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently. ■ True default: If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed. Some examples of where this property can be set to True are: read-only services for example, CreditRatingService or local EJBWSIF invocations that share the instances transaction.

13.3.2.2 nonBlockingInvoke

By default, Oracle BPEL Process Manager executes in a single thread, executing the branches sequentially instead of in parallel. When this property is set to True, the process manager creates a new thread to perform each branchs invoke activity in parallel. This property is applicable to both durable and transient processes. Consider setting this property to True if you have invoke activities in multiple flow or flow n branches. This is especially effective if the parallel invoke activities are two-way, but some benefits can be realized for parallel one-way invokes as well. Values: This property has the following values: ■ True: Oracle BPEL Server spawns a new thread to execute the invocation. ■ False default: Oracle BPEL Server executes the invoke activity in the single process thread.

13.3.2.3 validateXML

Enables message boundary validation. Note that additional validation can impact performance by consuming extra CPU and memory resources. Values: ■ True: When set to True the engine validates the XML message against the XML schema during receive and invoke for this partner link. If the XML message is invalid then bpelx:invalidVariables run time BPEL Fault is thrown. This overrides the domain level validateXML property. ■ False default: Disables XML validation.

13.4 Tables Impacted By Instance Data Growth

Instance data occupies space in Oracle BPEL Process Manager schema tables. Data growth from auditing and dehydration can have a significant impact on database performance and throughput. See Section 13.2.2, Audit Level for audit configuration and Section 13.3.1.1, inMemoryOptimization for dehydration configuration. The 13-8 Oracle Fusion Middleware Performance and Tuning Guide table below describes the tables that are impacted by instance data growth. A brief description is provided of each table. Table 13–1 Oracle BPEL Process Manager Tables Impacted by Instance Data Growth Table Name Table Description audit_trail Stores the audit trail for instances. The audit trail viewed in Oracle BPEL Control is created from an XML document. As an instance is processed, each activity writes events to the audit trail as XML. audit_details Stores audit details that can be logged through the API. Activities such as an assign activity log the variables as audit details by default. Audit details are separated from the audit_trail table due to their large size. If the size of a detail is larger than the value specified for this property, it is placed in this table. Otherwise, it is placed in the audit_trail table. cube_instance Stores process instance metadata for example, the instance creation date, current state, title, and process identifier cube_scope Stores the scope data for an instance for example, all variables declared in the BPEL flow and some internal objects that help route logic throughout the flow. dlv_message Stores incoming invocation and callback messages upon receipt. This table only stores the metadata for a message for example, current state, process identifier, and receive date. dlv_subscription 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. document_ci_ref Stores cube instance references to data stored in the xml_ document table. document_dlv_msg_ref Stores references to dlv_message documents stored in the xml_document table. wftask Stores tasks created for an instance. The TaskManager process keeps its current state in this table. work_item Stores activities created by an instance. All activities in a BPEL flow have a work_item table. This table includes the metadata for the activity current state, label, and expiration date used by wait activities. xml_document Stores all large objects in the system for example, dlv_ message documents. This table stores the data as binary large objects BLOBs. Separating the document storage from the metadata enables the metadata to change frequently without being impacted by the size of the documents. Headers_properties Stores headers and properties information.