B2B Installation

B2B Installation

Oracle B2B provides a platform to exchange standard messages between business entities. It comes with pre-built messaging templates and samples. It is part of Oracle SOA Suite. However, we need to separately download and install Oracle B2B Document editor. For traditional Oracle E-Business Suite users, this is similar to XML Gateway, but with more features geared towards SOA implementations.
Installation steps:

• Download Oracle B2B Document Editor from here. At the time of writing this article, installable came in three parts. Disk1 (File 1)  Disk1 (File 2)  Disk1 (File 3)

• Unzip all three zip files to their respective folders to create ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_1of3, ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_2of3, ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_3of3.
• Copy contents of Standards directory from ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_2of3, ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_3of3 into ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_1of3/Standards folder.
• Run ofm_b2b_doc_editor_win_11.1.1.1.0_disk1_1of3/Install.exe. Choose silent mode if you prefer so.

• Finally, installation confirmation screen will appear at the end of installation. I had about 51 folders under STANDARDS section of installation.

• Run from Programs.

• Access B2B console from Http://Host:ManagedServerPort/b2bconsole

Passing dynamic param to XSLT

There is no direct approach to it.However,looking into ora:XSLT signature,I found that we can pass BPEL variables as properties.Alternatively,one can pass multiple inputs in SOA 11g.

First things first,

                   1.>   params.xsd needs to be imported to project folder.The schema is structures as below:--

<?xml version="1.0" encoding="windows-1252" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

            xmlns="http://schemas.oracle.com/service/bpel/common"

            targetNamespace="http://schemas.oracle.com/service/bpel/common"

            elementFormDefault="qualified">

  <!-- Root Element for Parameters -->          

  <xsd:element name="parameters">

    <xsd:complexType>

      <xsd:sequence>

        <xsd:element name="item" minOccurs="1" maxOccurs="unbounded">

          <xsd:complexType>

            <xsd:sequence>

              <xsd:element name="name" type="xsd:string"/>

              <xsd:element name="value" type="xsd:string"/>

            </xsd:sequence>

          </xsd:complexType>

        </xsd:element>

      </xsd:sequence>

    </xsd:complexType>

  </xsd:element>

</xsd:schema>

2.> Define a variable of element type corresponding to above xsd. Let the name be parameterVar.

3    3.> Go to the composite.xml. Add the preference property as in the example below:--

  <component name="TestParams">

<implementation.bpel src="TestParams.bpel"/>

 <property name="bpel.preference.myPreference">HelloThere</property>

    </component>

4.                        

             4.>Go to the BPEL editor and drag a Assign activity. Following is how the resulting source code look like:--

                          <assign name="Assign_1">

            <copy>

                <from expression="indexName"/>

                <to variable=" parameterVar "

                    query="/ns4:parameters/ns4:item/ns4:name"/>

            </copy>

            <copy>

                <from expression="ora:getPreference('myPreference')"/>

                <to variable=" parameterVar "

                    query="/ns4:parameters/ns4:item/ns4:value"/>

            </copy>

        </assign>

5.                                                                                                                                                                                                                              

             5.> Drag a Transform activity. This will be the transformation from parameterVar to parameterVar. Map name to name and value to value inside transformation.

            <assign name="Transform_1">

            <bpelx:annotation>

                <bpelx:pattern>transformation</bpelx:pattern>

            </bpelx:annotation>

            <copy>

                <from expression="ora:processXSLT('xsl/Transformation_1.xsl',bpws:getVariableData(parameterVar))"/>

                <to variable=" parameterVar "/>

            </copy>

   </assign>

6.                                                                                                                                                                                                                                                                    

              6.>Once the above steps are completed. Next comes the passing of BPEL variable as third parameter in ora:XSLT signature. Inside the transformation, you need to add

 <xsl:param name=" indexName "/>. Note that indexname is same as assigned to name node of the  parameterVar.

Now this param can be used anywhere inside your XSLT by $indexName.

<assign name="MainXSLT">

            <bpelx:annotation>

                <bpelx:pattern>transformation</bpelx:pattern>

            </bpelx:annotation>

            <copy>

                <!-- Pass the additional Parameter <i> parameterVar </i> for the XSL Parameters -->

                <from expression="ora:processXSLT('TestParams.xsl',bpws:getVariableData('inputVariable','payload'),bpws:getVariableData(parameterVar))"/>

                <to variable="outputVariable" part="payload"/>

            </copy>

        </assign>

                     

Read more: http://www.soabyte.com

SOA Composite States

COMPOSITE_INSTANCE

State	Description
0	Running
1	Completed
2	Running with faults
3	Completed with faults
4	Running with recovery required
5	Completed with recovery required
6	Running with faults and recovery required
7	Completed with faults and recovery required
8	Running with suspended
9	Completed with suspended
10	Running with faults and suspended
11	Completed with faults and suspended
12	Running with recovery required and suspended
13	Completed with recovery required and suspended
14	Running with faults, recovery required, and suspended
15	Completed with faults, recovery required, and suspended
16	Running with terminated
17	Completed with terminated
18	Running with faults and terminated
19	Completed with faults and terminated
20	Running with recovery required and terminated
21	Completed with recovery required and terminated
22	Running with faults, recovery required, and terminated
23	Completed with faults, recovery required, and terminated
24	Running with suspended and terminated
25	Completed with suspended and terminated
26	Running with faulted, suspended, and terminated
27	Completed with faulted, suspended, and terminated
28	Running with recovery required, suspended, and terminated
29	Completed with recovery required, suspended, and terminated
30	Running with faulted, recovery required, suspended, and terminated
31	Completed with faulted, recovery required, suspended, and terminated
32	Unknown
64	Stale

Note:

SOA 11g Composite soainfra.composite_instances states you can calculate the states beyond the ones in the table above.

Example: state 80 (64+16) meaning STATE_STALE and STATE_TERMINATED_BY_USER

CUBE_INSTANCE

State	Description
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

DLV_MESSAGE

State	Description
0	STATE_UNRESOLVED
1	STATE_RESOLVED
2	STATE_HANDLED
3	STATE_CANCELLED
4	STATE_MAX_RECOVERED

DLV_TYPE

State	Description
1	Invoke Message
2	DLV Message

MEDIATOR_INSTANCE

State	Description
0	No faults but there still might be running instances
1	At least one case is aborted by user
2	At least one case is faulted (non-recoverable)
3	At least one case is faulted and one case is aborted
4	At least one case is in recovery required state
5	At least one case is in recovery required state and at least one is aborted
6	At least one case is in recovery required state and at least one is faulted
7	At least one case is in recovery required state, one faulted and one aborted
>=8 and < 16	Running
>= 16	Stale

Mediator Instance Tracking

There are in total 5 tables which are used by mediator instance tracking:

• Mediator_instance - One row for each mediator message flow.
• Mediator_case_instance - One row for each mediator case (~ routing rule).

If a mediator component has two routing rules then this should have 2 records for that mediator instance.

• Mediator_case_detail - Captures mediator audit trail for each mediator routing rule. Number of records may vary based on the nature of mediator component.

Eg:  if mediator component is having a async req-resp routing rule then this would contain 2 rows for the corresponding mediator routing rule.

• Mediator_document - Stores the payload for routing rules which are configured as deferred (~ parallel in jdev). So if all the routing rules are "sequential" then this will not contain any records.
• Mediator_audit_document - Stores the payload for audit trail and only when "instanceTrackingLevel" for mediator is "Complete".

In nutshell, of you want to know the number of messages getting past mediator then mediator_instance should be sufficient which captures the no of messages executed by Mediator.

Audit Trail Tracking

There are 2 audit trail tables used in BPEL: audit_trail and audit_details.

All audit trail events are inserted into audit_trail.  audit_details is used for the details section of an event (ie. payload); if a payload exceeds a

certain size, it is inserted into audit_details instead of being inlined in the audit_trail event.

There are 2 configuration settings for auditing:

auditLevel:

• off - absolutely no logging performed whatsoever; may result in a slight performance boost for processing instances.
• minimal - all events are logged; however, no audit details are logged.
• production - all events are logged.  The audit details for assign activities are not logged; the details for all other nodes are logged.
• development - all events are logged; all audit details for all activities are logged.

               

auditDetailThreshold:

                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.  Typically, the details string will contain the contents of a BPEL variable.  In cases where the variable is very large performance may be  severely impacted by logging it to the audit trail. The default value is 50  kilobytes.

There is no relation between instance tracking and BPEL auditing.  Instance tracking logs messages between components and on inbound/outbound wires.

BPEL auditing only pertains to BPEL instances and activities

Read more: http://www.soabyte.com/

oracle soa suite 11gr1 ps5 Main Enhancements

 EM – Alerts for stuck BPEL messages

An alert is displayed when there are stuck messages for asynchronous BPEL processes.

A global time threshold is used identify stuck messages.

Alerts displayed at multiple levels:

• Ø  soa-infra
• Ø  Composite
• Ø  Flow Trace (PS4)

System-wide MBean property to enable / disable BPEL message recovery alerts.

3 dimensional view of instance state:

• Ø  Execution state
• Ø  Fault
• Ø  Fault recovery needed

Enhanced search criteria.

Instances list can be filtered to instances with stuck BPEL messages.

 Link from “BPEL Recovery Required” alerts to BPEL recovery console.

ECID based search on BPEL recovery console. (PS4)

Testing BPEL Processes

Testing of an individual BPEL process as part of a SOA composite application test suite

• Ø  Variable and fault Assertions
• Ø  Assert Execution Counts
• Ø  Fast Forward for wait activities

New transaction properties for synchronous and one-way BPEL processes

Set the transaction behavior for initiating calls:

• Ø  Joins a caller's transaction or creates a new transaction (required)
• Ø  Uses the same thread in the same transaction (required)
• Ø  Creates a new transaction and existing transaction is suspended (requiresNew)

New delivery properties for asynchronous or one-way BPEL processes

Set the persistence policy in the delivery layer:

Messages into the system are saved before being picked up by the service engine

• Ø  In the delivery store (async.persist)
• Ø  In memory (async.cache)
• Ø  Or not at all (sync)

Property Inspector for Composite properties

 New property editor to set and edit composite properties, e.g  transaction and delivery properties of BPEL process

Dynamic partner links in a BPEL process

If using a WSDL with multiple services that use the same portType, the dynamic partner link allows to dynamically assigning an endpoint reference to a partner link for use at runtime

Specifying XPath expressions to bypass (skip) activity execution now also in BPEL 2.0

• Ø  Skip an activity if an XPath expression evaluates to true
• Ø  Provides an alternative to using a switch activity for conditionally executing activities

Throwing faults with assertion conditions now also in BPEL 2.0

Assertion condition is executed upon receipt of a callback message.

• Ø  If XPath expression is evaluated to false, BPEL fault will be thrown from the activity
• Ø  Pre Assert: Condition is executed before the invoke or reply activity sends out the outbound message
• Ø  Post Assert: Condition is executed after an invoke activity, receive activity, or onMessage branch receives the inbound message

Setting Timeouts for Request-Reply and InOnly Operations in Receive Activities now also in BPEL 2.0

Provides a timeout setting for:

• Ø  Request-reply (synchronous) operations
• Ø  In-only receive (asynchronous) operations

Alternative to using the onMessage and onAlarm branches of a pick activity to specify a timeout duration for partner callbacks.

Copy and paste in a BPEL process.

• Ø  Copy and paste activities in the same BPEL project or between BPEL projects
• Ø  Design an activity once and use it in multiple places, editing it as necessary

Infrastructure Platform Enhancements

• Ø  Reduced Memory Footprint: Lower memory (JVM heap) requirements associated with composite deployments.
• Ø  Additional HA capabilities:

·         Support for Active GridLink for RAC: No need to define one datasource per RAC instance. Faster failover.

·         Multi-data source continues to be supported and more hardened

·         DB persistence for Tx logs – Eliminates need for shared disks. Performance impact not assessed at this point.

Purge Enhancements

• Ø  Partition based purging: Row movement of active instances of long running processes to enable dropping a partition.
• Ø  Hybrid approach: Partition only a subset of high volume tables.
• Ø  Purge optimizations: Avoid redundant pruning of data, additional indexes etc.
• Ø  Purge by composite name: Purge instances associated with a specific composite name.

Read more: http://www.soabyte.com