Customizing an ebXML Participant Business Process

After you create an ebXML participant business process, you must customize it for the associated ebXML conversation. Common customization tasks include:

Depending on your implementation requirements, you might make additional customizations to the participant business process as needed. For example, participant business processes typically invoke other controls (such as the File, JMS, or Application View controls), or a subprocess, to accomplish the necessary backend integration.

Configuring Business Process Properties (Required)

The generated ebXML participant business process file specifies the following default annotations:

@jpd:ebxml protocol-name="ebxml" ebxml-service-name="serviceName" ebxml-action-mode="non-default" 

These properties are set in the Property Editor that is visible when you have the Start node of your business process selected. Review and edit (if needed) the following properties:

Property
Default
Description

protocol-name

ebxml

Do not change.

service-name

serviceName

Name of the ebXML service associated with this business process. The name specified here must match the service name specified on the initiator side (for example, in the ebxml-service-name annotation on the ebXML control in the initiator business process). You provide this service name to your trading partners.

action-mode

non-default

Action mode for this business process. Determines the value specified in the eb:Action element in the message header of the ebXML message, which becomes important in cases where multiple message exchanges occur within the same conversation. Select one of the following values:

  • default—Sets the eb:Action element to SendMessage (default name).
  • non-default—Sets the eb:Action element to the name of the method (on the ebXML control) that sends the message in the initiator business process. For sending a message from the initiator to the participant, this name must match the method name of the Client Request node in the corresponding participant business process. For sending a message from the participant to the initiator, the method name in the callback interface for the Client Callback node in the participant business process must match the method name (on the ebXML control) in the control callback interface in the initiator business process. Using non-default is recommended to ensure recovery and high availability.

If unspecified, the ebxml-action-mode is set to non-default.

Note: If the Property Editor is not visible in the Design View, choose View —> Property Editor from the WebLogic Workshop menu.

To learn more about ebXML annotations, see @jpd:ebxml Annotation. To learn about configuring business process properties, see Business Process Language.

Customizing Names and Argument Types (Optional)

By default, the ebXML participant business process includes a Client Request node, named Receive request, to handle an incoming ebXML request message from an initiator. For business processes that involve multiple round-trips, you need to create additional Client Request nodes for any other operations that involve that receive an ebXML message from the initiator. To add the node to a business process, drag image Client Request from the Data Palette onto the business process.

After creating a Client Request node, for the request method, specify the attachment and its Java data type for the incoming message. The data type must match the contents of the incoming message and can be one of the following values:

Data Type
Description

XmlObject

Default. Represents data in untyped XML format. The XML data is not specified at design time.

XmlObject[]

An array containing one or more XmlObject elements.

RawData

Represents any non-XML structured or unstructured data for which no MFL file (and therefore no known schema) exists.

RawData[]

An array containing one or more RawData elements.

MessageAttachment[]

Array containing one or more parts of an ebXML business message. Message parts can be untyped XML data (XmlObject data type) or non-XML data (RawData data type). Used when sending different kinds of payloads (XML and non-XML) in the same message. The actual number of message parts might not be known until processed. To learn about working with MessageAttachment objects, see Using Message Attachments.

Note: Attachments can also be typed XML or typed MFL data as long as you specify the corresponding XML Bean or MFL class name in the parameter. To learn more about data types, see Working with Data Types.

The following restrictions apply to payload specifications:

Retrieving the ebXML Message Envelope (Optional)

You can retrieve the message envelope of an incoming ebXML message by using the message-envelope annotation in the @jpd:ebxml-method tag, as shown in the following example:

/**
*@jpd:ebxml-method message-envelope="{env}"
*/
public void request(XmlObject payload, XmlObject env)  {
} 

Note: You can rename the default value (env) as long as it matches the name of the parameter specified in the method.

To learn more about the message-envelope annotation, see @jpd:ebxml-method Annotation.

Related Topics

About the ebXML Participant Business Process File

Creating an ebXML Participant Business Process

Previous Document Next Document