bea weblogic integration · beaweblogic integration ™ annotations reference version 8.1 service...

BEA
WebLogic Integration™
Annotations Reference

Version 8.1 Service Pack 4Document Date: December 2004

CopyrightCopyright © 2004-2005 BEA Systems, Inc. All Rights Reserved.

Restricted Rights LegendThis software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc.

Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software--Licensing clause at NASA FAR supplement 16-52.227-86; or their equivalent.

Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE.

Trademarks or Service MarksBEA, BEA WebLogic Server, Jolt, Tuxedo, and WebLogic are registered trademarks of BEA Systems, Inc. BEA Builder, BEA Campaign Manager for WebLogic, BEA eLink, BEA Liquid Data for WebLogic, BEA Manager, BEA WebLogic Commerce Server, BEA WebLogic Enterprise, BEA WebLogic Enterprise Platform, BEA WebLogic Enterprise Security, BEA WebLogic Express, BEA WebLogic Integration, BEA WebLogic JRockit, BEA WebLogic Personalization Server, BEA WebLogic Platform, BEA WebLogic Portal, BEA WebLogic Server Process Edition, BEA WebLogic Workshop and How Business Becomes E-Business are trademarks of BEA Systems, Inc.

All other trademarks are the property of their respective companies.

Contents


Common Annotations@common:context Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

@common:control Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-2

Integration Controls Annotations

Application View Control Annotations@jc:av-identity Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

@jc:av-service Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-3

Dynamic Transformation Control Annotations@jc:ddtf Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

@jc:xquery Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-2

@jc:xslt Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-3

ebXML Control Annotations@jc:ebxml Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-2

@jc:ebxml-method Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-3

Email Control Annotations@jc:email Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1

@jc:send-email Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3

Annotations Reference iii

File Control Annotations@jc:file Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-1

@jc:file-operation Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3

Http Control Annotations@jc:httpsend-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-1

JMS Control Annotations

Message Broker Control Annotations@jc:mb-publish-control Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

@jc:mb-publish-method Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-2

@jc:mb-subscription-control Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

@jc:mb-subscription-method Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-3

@jc:mb-subscription-callback Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-4

MQSeries Control AnnotationsMQSeries Control Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-1

@jc:MQConnectionType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

@jc:MQConnectionPoolProps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

@jc:ConnectionPoolTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-2

@jc:ConnectionRetrySettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

@jc:MQQueueManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-3

@jc:MQAuthorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

@jc:TCPSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-4

@jc:SSLSettings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-5

@jc:DefaultQueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-6

@jc:ImplicitTransaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12-7

iv Annotations Reference

Process Control Annotations

RosettaNet Control Annotations@jc:rosettanet Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14-1

Service Broker Control Annotations

Worklist Control Annotations@jc: advanced Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-3

@jc:assignee Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5

@jc:select Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-5

@jc:task Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-8

@jc:task-abort Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9

@jc:task-assign Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-9

@jc:task-claim Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10

@jc:task-complete Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-10

@jc:task-create Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-11

@jc:task-delete Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13

@jc:task-event Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-13

@jc:task-get-info Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-14

@jc:task-get-property Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16

@jc:task-get-property-name Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16

@jc:task-get-request Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-16

@jc:task-get-response Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17

@jc:task-remove-property Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17

@jc:task-resume Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-17

@jc:task-return Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18

@jc:task-set-property Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-18

@jc:task-start Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19

Annotations Reference v

@jc:task-stop Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-19

@jc:task-suspend Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20

@jc:task-update Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-20

@jc:task-worker Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16-21

Business Process Annotations@jpd:ebxml Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-3

@jpd:ebxml-method Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-4

@jpd:mb-static-subscription Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-5

@jpd:process Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-7

@jpd:rosettanet Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-9

@jpd:selector Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-10

@jpd:transform Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-11

@jpd:unexpected-message Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-12

@jpd:version Annotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-13

@jpd:xml-list Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14

@jpd:xquery Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-14

@common Annotations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-15

Web Service Features in Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-16

General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-20

Message Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-21

Method Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-21

Variable Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-22

Control Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17-22

Data Transformation Annotations@dtf:xquery Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-2

@dtf:transform Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-4

vi Annotations Reference

@dtf:schema-validate Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-8

@dtf:xquery-function Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-9

General Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18-10

Annotations Reference vii

viii Annotations Reference

C H A P T E R 1


This section provides reference information about WebLogic Integration-specific Workshop annotations, which are formatted like Javadoc tags.

WebLogic Workshop provides custom annotations based on Javadoc technology. Originally developed as a way to embed documentation into source code as comments, Javadoc is extended by WebLogic Workshop through custom annotations that help to define the functionality of a Web application component. For example, in WebLogic Integration, annotations can be used to define the purpose of an Integration control or a business process.

To learn about Workshop annotations not specific to WebLogic Integration (that is, Web service annotations, page flow annotations, and so on), see the WebLogic Workshop Reference.

Topics Included in This SectionCommonAnnotations Reference

Provides reference information for common annotations. Common annotations are those annotations that are available to more than one type of file (JWS, JXCX, JPD, and so on) in WebLogic Workshop.

Integration Controls Annotations ReferenceThis section provides reference information for WebLogic Integration controls annotations.

Business Process Annotations ReferenceThis section provides reference information for WebLogic Integration business process (JPD) annotations (that is, annotations that are of the following format: @jpd:name_of_annotation).

Annotations Reference 1-1

http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/navCajunRef.html

Anno ta t ions Re fe rence

Data Transformation AnnotationsThis section provides reference information for WebLogic Integration data transformation (DTF) annotations (that is, annotations that are of the following format: @dtf:name_of_annotation).

1-2 Annotations Reference

C H A P T E R 2

Common Annotations

This section provides reference information for common annotations. Common annotations are available to more than one type of file in WebLogic Workshop.

Topics Included in This Section@common:context Annotation

Specifies to WebLogic Server the type of component for which it creates a context. The components include business processes, controls, Web services and so on.

@common:control AnnotationSpecifies that the object annotated by this annotation is a WebLogic Workshop control in a JCX file.

@common:context AnnotationThe @common:context annotation specifies that WebLogic Server should create a context for the component, such as a business process or a control. The context ensures that conversations between the component and a client are correlated correctly and that the component's state is maintained. The @common:context annotation precedes the declaration of the context object; the type of the context object depends on the container you are using. For business processes, the context object is of type JpdContext; for controls, ControlContext.

Syntax@common:context

Business Process Annotations Reference 2-1

Common Annota t ions

AttributesNone.

RemarksThe following rules apply to this annotation's use:

Only one @common:context annotation may appear within a single Javadoc comment block.

The @common:context annotation must appear on the instance declaration of the context object.

For example, the annotation and instance declaration for the JpdContext object appear as follows:

/** @common:context */

JpdContext context;

If the @common:context annotation is not present on the instance declaration, the component that defines it does function properly.

Related TopicsjpdContext Interface

@common:control AnnotationThe @common:control annotation indicates that the object annotated by this annotation is a WebLogic Workshop control in a JCX file.

Syntax@common:control

AttributesNone.


2-2 Business Process Annotations Reference

http://edocs.bea.com/workshop/docs81/doc/en/integration/java-class/com/bea/jpd/JpdContext.html

@common: cont ro l Anno ta t i on

Only one @common:control annotation can be specified within a single Javadoc comment block.

Must appear on each control instance declaration.

If the @common:control annotation is not present on a control instance declaration, the control will not function properly; attempts to invoke the control’s methods will result in Null Pointer Exceptions (NPEs).

Related TopicsUsing Integration Controls


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsIntro.html

Common Annota t ions


C H A P T E R 3

Integration Controls Annotations

This section provides reference information for WebLogic Integration controls annotations.

Topics Included in This SectionChapter 4, “Application View Control Annotations”

Describes the Application View control annotations.

Chapter 5, “Dynamic Transformation Control Annotations”

Describes the Dynamic Transformations control annotation.

Chapter 6, “ebXML Control Annotations”Describes the ebXML control annotations.

Chapter 7, “Email Control Annotations”Describes the Email control annotations.

Chapter 8, “File Control Annotations”Describes the File control annotations.

Chapter 9, “Http Control Annotations”Describes the Http control annotations.

Chapter 10, “JMS Control Annotations”Describes the JMS control annotations.

Integration Controls Annotations Reference 3-1

In tegrat ion Cont ro ls Anno ta t ions

Chapter 11, “Message Broker Control Annotations”Describes the Message Broker Publish and Message Broker Subscription control annotations.

Chapter 12, “MQSeries Control Annotations”Describes the MQSeries control annotations.

Chapter 13, “Process Control Annotations”Describes the Process control annotations.

Chapter 14, “RosettaNet Control Annotations”Describes the RosettaNet control annotations.

Chapter 15, “Service Broker Control Annotations”Describes the Service Broker control annotations.

Chapter 16, “Worklist Control Annotations”Describes the Worklist control (Task control and Task Worker control) annotations.

Note: There is a TPM Control, but this control has no annotations.

3-2 Integration Controls Annotations Reference

C H A P T E R 4

Application View Control Annotations

The Application View control annotations provide information to WebLogic Server about how the control functions. This section contains information about the Application View control annotations, including the syntax to use and the available attributes that can be set for the control.

Topics Included in This Section@jc:av-identity Annotation

Specifies the target Application View for an Application View control.

@jc:av-service AnnotationSpecifies the Application View service associated with a method of an Application View control.

@jc:av-identity AnnotationSpecifies the target Application View for an Application View control.

Note: The @jc:av-identity annotation appears in Application View controls with the .jcx extension. Application View controls with the .ctrl extension, which were created in a previous version of WebLogic Workshop, use the @jws:av-identity annotation. Controls with the .ctrl extension continue to be supported in WebLogic Workshop.


App l i ca t i on Vi ew Cont ro l Annotat ions

Syntax@jc:av-identity

name="applicationViewName"app="applicationName"namespaceEnforcementEnabled="true | false"

Attributesname

Required. Specifies the name of the target Application View. The name is fully qualified and dot separated. The Application View must be deployed before the Application View control will function.

appRequired. Specifies the name of the associated WebLogic Workshop application. This is usually the same as the current WebLogic Workshop application.

This parameter allows you to reuse an application view between WebLogic Workshop applications. First, define the application view in the context of the primary application. Then, define an Application View control in a process within a second application and specify the primary application in the app parameter. When reusing an application view from another application, all services are accessed synchronously.

namespaceEnforcementEnabledIf true, indicates that the client requires response instances and event instances to declare the namespace indicated in the response/event definitions, and force the proper namespace declaration onto the response/event if needed. Some legacy adapters do not provide responses/events using the namespaces declared in the response/event schema. This option allows clients that perform schema-based XML checking to use such adapters. The option is disabled by default, because it can have serious performance implications for adapters that return their responses/events as raw XML text (not parsed). In this case, this option forces a parse of the XML text in order to inject the proper namespace declaration.


Only one @jc:av-identity annotation may appear within a single Javadoc comment block.

The @jc:av-identity annotation may appear in the Javadoc comment on the main interface defined in a Application View control's JCX file.


@jc: av-se rv ice Anno ta t i on

Related TopicsApplication View Control

@jc:av-service Annotation

@jc:av-service AnnotationSpecifies the Application View service associated with a method of an Application View control.

Note: The @jc:av-service annotation appears in Application View controls with the .jcx extension. Application View controls with the .ctrl extension, which were created in a previous version of WebLogic Workshop, use the @jws:av-service annotation. Controls with the .ctrl extension continue to be supported in WebLogic Workshop.

Syntax@jc:av-service

name="avServiceName"async="true | false"

Attributesname

Required. Specifies the name of the service in the target Application View with which this Application View control method is associated.

asyncRequired. Specifies whether or not the service is asynchronoous. The default value is false (synchronous).


The @jc:av-service annotation may only occur on a method declaration in an interface that extends weblogic.jws.control.ApplicationViewControl.

The @jc:av-service annotation may only occur in a JCX file.

The @jc:av-service annotation may only appear once per method.


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsAppView.html

App l i ca t i on Vi ew Cont ro l Annotat ions

Related TopicsApplication View Control

@jc:av-identity Annotation


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsAppView.html

C H A P T E R 5

Dynamic Transformation Control Annotations

This section describes the Dynamic Transformation control annotations.

Topics Included in This Section@jc:ddtf Annotation

@jc:xquery Annotation

@jc:xslt Annotation

@jc:ddtf AnnotationSpecifies the XQuery functions that can be used by the queries and the type of encoding used a design time.

Syntax@jc:ddtf

[xquery-prologue=""][control-design-time-encoding=""]

Example:/** * @jc:ddtf xquery-prologue::* define function debugFunction(xs:string $str) returns xs:string {* concat("DTF XQuery: ", $str) }* ::


Dynamic T rans fo rmat ion Cont r o l Annotat ions

* control-design-time-encoding="Cp1252" */

Attributesxquery-prologue

Defines the global XQuery functions that can be used by the queries specified in the Transformation Control. (The call to the function is made in the XQuery file that contains the query.) In addition, the @dtf:xquery-prologue annotation with the prologue attribute specifies XQuery namespaces that can be used within the scope of the prologue of the transformation Control.

control-design-time-encodingSpecifies the encoding, such as UTF-8, of the control used by the base methods at design time.

@jc:xquery AnnotationSpecifies the XQuery files and their attributes for XQuery transformations at run time.

Syntax@jc:xquery

[xquery-arg-names=""][validate-parms="true|false"][validate-return="true|false"][design-time-encoding=""]

Example:/*** @jc:xquery design-time-encoding="Cp1252" xquery-arg-names="" validate-return="false" validate-parms="false"*/

AttributesSpecifies attributes to be used for XQuery transformations.

xquery-arg-names

Contains the semicolon-separated list of argument names used during the XQuery execution at run time. If an XQuery definition has the following signature:

ConvertPO(String Xqname, String PO, PoDocument poDoc)


@jc:xs l t Annota t i on

the attribute values would be:

PO;poDoc.

validate-parmsAt run time, when true, validates the parameters for typed XML documents.

validate-returnAt run time, when true validates the return type for typed XML documents.

design-time-encodingStores the encoding, such as UTF-8, or the .xq files at design time

@jc:xslt AnnotationSpecifies the XSL file to be used for the transformation.

Syntax@jc:xslt

[xslt-arg-names=""]

AttributesSpecifies the name of the XSL file to be used for the transformation.

xslt-arg-names

Contains the comma-separated values argument names used in the XSL file during the XSLT run-time execution.


Dynamic T rans fo rmat ion Cont r o l Annotat ions


C H A P T E R 6

ebXML Control Annotations

The ebXML control enables WebLogic Workshop business processes to exchange business messages and data with trading partners via ebXML. The ebXML control supports both the ebXML 1.0 and ebXML 2.0 messaging services. You use ebXML controls in initiator business processes to manage the exchange of ebXML business messages with participants.

This section contains information about ebXML control annotations, including the syntax to use and the available attributes that can be set for the control.

Topics Included in This Section@jc:ebxml Annotation

Specifies the JCX class-level annotations for the ebXML control

@jc:ebxml-method AnnotationSpecifies the method-level annotations for the ebXML control.


ebXML Cont ro l Annota t ions

@jc:ebxml AnnotationSpecifies JCX class-level annotations for the ebXML control.

Note: For most attributes, annotations can also be specified at the instance and method level. The order of precedence is:

1. JCX method level.

2. JCX instance level.

3. JCX class level.

Syntaxjc:ebxml

[from="initiatorID"] | [from-selector="{xquery-expression}"]

[to="participantID"] | [to-selector="{xquery-expression}"]

[ebxml-service-name="ebxml-service-name"]

[ebxml-action-mode="default | non-default"]

Attributesfrom

Business ID of the initiator. Must match the business ID for the trading partner as defined in the TPM repository.

from-selectorXQuery expression that selects the business ID of the initiator. To learn how to specify the initiator business ID dynamically, see "Dynamically Specifying Business IDs" in Using an ebXML Control.

Note: This attribute is not available for all methods at the control type level in the control definition file (JCX file). It only applies to the send method in the control definition or to control instance declarations in the business process file (JPD file).

toBusiness ID of the participant. Must match the business ID for the trading partner as defined in the TPM repository.

to-selectorXQuery expression that selects the business ID of the participant. To learn how to specify the participant business ID, see "Dynamically Specifying Business IDs" in Using an ebXML Control.


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsebXMLUsing.html



@jc: ebxml-method Anno ta t i on

Note: This attribute is not available for all methods at the control type level in the control definition file (JCX file). It only applies to the send method in the control definition or to control instance declarations in the business process file (JPD file).

ebxml-service-nameName of an ebXML service. For initiator and participant business processes that participate in the same conversation, the settings for ebxml-service-name must be identical. This service name corresponds to the eb:Service entry in the ebXML message envelope.

ebxml-action-modeAction mode for this ebXML control. 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. 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.

Related Topics@jc:ebxml-method Annotation

@jc:ebxml-method AnnotationSpecifies method-level annotations for the ebXML control.

Syntaxjc:ebxml-method

[to-selector="{xquery-expression}"]

[envelope="{env}"]


ebXML Cont ro l Annota t ions

Attributesto-selector

XQuery expression that selects the recipient business ID. To learn how to specify the business ID dynamically using selectors in the Property Editor, see "Dynamically Specifying Business IDs" in Using an ebXML Control.

envelopeUsed with a callback method to assign the ebXML envelope of an incoming message.

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

Related Topics@jc:ebxml Annotation



C H A P T E R 7

Email Control Annotations

This section describes the Email control annotations.

Topics Included in This Section@jc:email Annotation

@jc:send-email Annotation

@jc:email AnnotationSpecifies class- and method-level configuration attributes for the Email control.

Syntaxjc:email

[from-address="from-address"][from-name="from-name"][smtp-address="smtp-address"][reply-to-address="reply-to-address"][reply-to-name="reply-to-name"][smtp-username="smtp-username"][smtp-password="smtp-password"][smtp-password-alias="smtp-password-alias"][header-encoding="header-encoding"]


Emai l Cont ro l Annota t ions

AttributesThese attributes determine the default behavior of the Email control. The Email control may be configured during its lifetime by calling methods of the EmailControl class.

from-addressA string containing the originating e-mail address. This attribute is required if the from-name attribute is present.

from-nameA string containing the display name for the originating e-mail address. This attribute is optional.

smtp-addressA string containing the address of the SMTP server in host:port or host form. If the port is not specified, the standard SMTP port of 25 is used. This attribute is required.

reply-to-addressA string containing the e-mail address to reply to. This attribute is required if the reply-to-name attribute is present.

reply-to-nameA string containing the display name for the reply-to-address. This attribute is optional.

smtp-usernameA string containing the username for server’s that require authentication to send. This attribute is optional.

smtp-passwordA string containing the associated password. This attribute is optional.

smtp-password-aliasA string containing the password alias. The alias is used to look up the password in the password store. This attribute is optional and is mutually exclusive with the smtp-password attribute.

header-encodingA string specifying the encoding to be used for the mail headers as specified by from-name, reply-to-name, to, bc, bcc, subject, and attachments. If no header encoding is specified, the system default encoding is used.

Related TopicsEmail Control


http://e-docs.bea.com/workshop/docs81/doc/en/integration/controls/controlsEmail.html

@jc :send-emai l Annota t i on

@jc:send-email Annotation

@jc:send-email AnnotationSpecifies class- and method-level configuration attributes for the Email control.

Syntaxjc:send-email

[to="To-recipients"][cc="CC-recipients"][bcc="BCC-recipients"][subject="subject"][body="body"][content-type="content-type"][attachments="file-list"]

AttributesThese attributes determine the default behavior of the Email control. The Email control may be configured during its lifetime by calling methods of the EmailControl class.

Parameter substitution can be used for any of the following method attributes. Substitutions are allowed in the middle of the subject or body. For example, upon receiving an order, you can send the following e-mail:

“Thanks for your order. Your order number is {orderNumber}.

Please reference this number in all your future correspondence."

toThe list of To recipients. This attribute takes a comma separated list of Strings. This attribute is required.

ccThe list of CC recipients. This attribute takes a comma separated list of Strings. This attribute is optional.

bccThe list of BCC recipients. This attribute takes a comma separated list of Strings. This attribute is optional.

subjectA string containing the subject of the e-mail. This attribute is optional.


Emai l Cont ro l Annota t ions

bodyA string containing the body of the e-mail. This attribute is optional.

content-typeA string containing the content-type of the body. If not specified, the default is text/plain for String bodies and text/xml for XmlObject bodies. Aside from the default text/plain, expected content types include text/html, text/xml, and application/xml. This attribute is optional.

attachmentsThe list of files to send as attachments. This attribute takes a comma separated list of Strings. This attribute is optional.

Unqualified paths specifying attachment locations are relative to the location of the domain’s startWeblogic command file. Because the domain root may be deep in the directory structure, we recommend the use of absolute paths for specifying attachment locations.

The to and cc recipient lists can include display names as shown in the following examples:

Joe User <[email protected]>, Jane User <[email protected]>

"Joe A. User" <[email protected]>, "Jane B. User" <[email protected]>

Related TopicsEmail Control

@jc:email Annotation


http://e-docs.bea.com/workshop/docs81/doc/en/integration/controls/controlsEmail.html

C H A P T E R 8

File Control Annotations

This section describes the File control annotations.

Topics Included in This Section@jc:file Annotation

@jc:file-operation Annotation

@jc:file AnnotationSpecifies the annotations for the File control.

Syntax@jc:file

[directory-name="directory name"][file-mask="file name or file mask"][suffix-name="file name suffix"][suffix-type="timestamp or index"][create-mode="over-write or rename-old"][ftp-host-name="ftp host name"][ftp-username-name="ftp user name"][ftp-password="password"][ftp-password-alias="password alias"][ftp-local-directory="local directory name"]


Fi l e Cont ro l Annotat ions

AttributesThese attributes determine the default behavior of the File control. The File control can be configured during its lifetime by calling methods of the FileContol class. To learn more about the FileControl class, see the javadoc for the File Control.

directory-nameA directory name is the absolute path name for the directory. In other words, it includes the drive specification as well as the path specification. For example, following are valid directory names:

C:\directory (Windows)

/directory (Unix)

\\servername\sharename\directory (Win32 UNC)

The directory-name attribute is required. Leaving the directory-name attribute unspecified results in an error.

file-maskThe file-mask attribute can specify either a file name or a file mask. If the file-mask contains a wild-card character (such as “*”) it will be treated as a file mask. Typically, a wild-card character is specified to get the list of files in a directory. It is illegal to specify a wild-card character for any other operation.

File names are used for read, write and append operations.

suffix-nameThis suffix will be used along with a timestamp or incrementing index for creating the file names. The default suffix-name will be “_”. For example:

file_01, file_02, file_0809021230123

suffix-typeThis option specifies if a timestamp or an incrementing index should be used as a suffix for the file names. The allowed options are: index and timestamp.

create-modeThis option specifies what needs to be done when a write operation is creating a new file and a file with the same name already exists. The allowed options are: over-write and rename-old.


@j c: f i l e -ope ra t i on Annota t i on

When you use create-mode="rename=old" to rename a file, make sure that you mention the suffix-name and the suffix-type attributes for the new file name. If the suffix attributes are not indicated, then the File control overwrites the old file, instead of renaming it.

ftp-host-nameThis option specifies the name of the FTP host, for example, ftp://ftp.bea.com.

ftp-user-nameThis option specifies the name of the FTP user.

ftp-passwordThis option specifies the FTP user’s password. If you specify this attribute, you cannot specify the ftp-password-alias attribute.

ftp-password-aliasThis option specifies the alias for a user’s password. The alias is used to look up a password in a password store. If you specify this attribute, you cannot specify the ftp-password attribute.

ftp-local-directoryThis option specifies the directory used for transferring files between the remote file system and the local file system. When reading a remote file, the file is copied from the remote system to the local directory and then read. Similarly, when writing to a remote file system, the file is written to the local directory and then copied to the remote system.

Related TopicsFile Control

@jc:file-operation Annotation

@jc:file-operation AnnotationSpecifies configuration attributes for a File control.

Syntax@jc:file-operation

[io-type="read, readline, write or append"][file-content="file content description"][record-size="number of bytes per record"][encoding="character set encoding"]


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsFile.html

Fi l e Cont ro l Annotat ions

AttributesThese attributes determine the default behavior of the File control. The File control can be configured during its lifetime by calling methods of the FileContol class. To learn more about the FileControl class, see the javadoc for the File Control.

io-typeThis attribute specifies the type of operation. The valid values are: read, write, append and readline. (To learn about the readline value, see record-size).

file-contentThis attribute indicates the contents of the identified variable which will be written to the file.

record-sizeThis option is used with methods of type @jc:file-operation io-type="readline". The record size, a positive integer, is expressed in bytes.

The record-size attribute is valid for methods with a return type of RawData and String, but not XmlObject. If this attribute is not specified, the default platform-specific line delimiters, such as carriage returns or line feeds, are used.

The following code illustrates the use of the record-size attribute:

/** * @jc:file-operation io-type="readline" record-size="80" */

RawData readLine();

encodingThis option is used to specify the character set encoding for the file. The file type must be String or XMLObject. This option can not be used if large files are being processed.

Related TopicsFile Control

@jc:file Annotation


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsFile.html


C H A P T E R 9

Http Control Annotations

This section describes the Http control annotations that are present in the JCX file of the Http control.

Topics Included in This Section@jc:httpsend-data

@jc:httpsend-dataSpecifies the URL to which an Http message is to be sent, and from which response is to be received.

Syntax@jc:httpsend-data url-name

[url-name="name of the URL"]

Http Cont ro l Annota t i ons


C H A P T E R 10

JMS Control Annotations

The JMS Control annotations provide information to WebLogic Server about how the control functions.

The WLI JMS control is an extension of the JMS control. The following JMS control annotations also apply to the WLI JMS control:

@jc:jms-headers Annotation

@jc:jms-property Annotation

Related TopicsWLI JMS Control


http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/jms-headers.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/jms-property.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsJMS.html

JMS Cont ro l Annota t i ons


C H A P T E R 11

Message Broker Control Annotations

This section describes the Message Broker Publish and Subscription control annotations.

Topics Included in This Section

Message Broker Publish Control Annotations@jc:mb-publish-control Annotation

Defines class level attributes for the Publish control.

@jc:mb-publish-method AnnotationDefines method level attributes for the Publish control.

Message Broker Subscription Control Annotations@jc:mb-subscription-control Annotation

Defines class level attributes for the Subscription Control.

@jc:mb-subscription-method AnnotationDefines method level attributes for the Subscription Control.

@jc:mb-subscription-callback AnnotationDefines callback attributes for the Subscription Control.


Message Broker Cont r o l Anno ta t ions

@jc:mb-publish-control AnnotationThis section describes the class attributes supported for the Publish control.

Syntax@jc:mb-publish-control

[channel-name="channel name"][message-metadata="message metadata"]

Attributeschannel-name

The name of the Message Broker channel to which the MB Publish control publishes messages.

message-metadataBy default, this XML header is included in messages published with this control. Valid values include a string containing XML.

Related TopicsMessage Broker Publish Control

@jc:mb-publish-method AnnotationThis section describes the method attributes supported for the Publish control.

Syntax@jc:mb-publish-method

[message-metadata="message metadata"][message-body="message body"]

Attributesmessage-metadata

XML header to include in messages published with the control method to which it is associated. Valid values include a string containing XML, or a method parameter in curly braces. For example: {parameter1}.


http://e-docs.bea.com/workshop/docs81/doc/en/integration/controls/controlsBrokerPublish.html

@jc :mb-subsc r i pt ion-con t ro l Anno ta t i on

message-bodyValid values include a string containing text that is used as the message body in the published message, or a method parameter in curly braces. For example: {parameter2}.

Related TopicsMessage Broker Publish Control

@jc:mb-subscription-control AnnotationThis section describes the class attributes supported for the Subscription control.

Syntax@jc:mb-subscription-control

[channel-name="channel name"][xquery="xquery"]


The name of the Message Broker channel to which the control subscribes. This is a required class-level annotation that cannot be overridden.

xqueryThe XQuery expression that is evaluated for each message published to a subscribed channel. Messages that do not satisfy this expression are not dispatched to a subscribing business process. This is an optional class-level annotation that cannot be overridden.

Related TopicsMessage Broker Subscription Control

@jc:mb-subscription-method AnnotationThis section describes the method attributes supported for the Subscription control.

Syntax@jc:mb-subscription-method

[filter-value-match="filter value match"]


http://e-docs.bea.com/workshop/docs81/doc/en/integration/controls/controlsBrokerPublish.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/controls/controlsBrokerSubscribe.html

Message Broker Cont r o l Anno ta t ions

Attributesfilter-value-match

The filter-value that the XQuery expression results must match for the message to be dispatched to a subscribing business process. This is an optional method-level annotation. Valid values for the filter-value-match annotation include a string constant that is compared directly to the XQuery results, or a method parameter in curly braces. For example: {parameter1}


@jc:mb-subscription-callback AnnotationThis section describes the callback attributes supported for the Subscription control.

Syntax@jc:mb-subscription-callback

[message-metadata="message metadata"][message-body="message body"]

Attributesmessage-metadata

The name of a parameter in the callback method that receives the metadata from the message that triggered the subscription. This parameter can be of an XmlObject or typed XML.

message-bodyThe name of a parameter in the callback method that receives the body from the message that triggered the subscription. This parameter must be of type XmlObject (or a typed XBean), String, RawData, or a non-XML MFL class (a subclass of MflObject).





Integration Controls Annotations Reference 121

C H A P T E R 12

MQSeries Control Annotations

This section describes the MQSeries control annotations that are present in the MQSeries control JCX file.

MQSeries Control AnnotationsThis section includes information on MQSeries control annotations.

Topics Included in This Section@jc:MQConnectionType

@jc:MQConnectionPoolProps

@jc:ConnectionPoolTimeout

@jc:ConnectionRetrySettings

@jc:MQQueueManager

@jc:MQAuthorization

@jc:TCPSettings

@jc:DefaultQueue

@jc:ImplicitTransaction

MQSer ies Cont ro l Annota t i ons

122 Integration Controls Annotations Reference

@jc:MQConnectionTypeSpecifies the connection type for an MQSeries control.

Syntax@jc:MQConnectionType

[connectionType="TCP|Bindings"]

AttributesThis attribute determines the type of connection to an MQSeries queue manager.

connectionType

The connection type can be TCP or Bindings. When the Bindings type of connection is used, WebLogic Workshop application and the MQSeries server are running on the same machine. When the TCP connection type is used, WebLogic Workshop application and the MQSeries server may be running on different machines.

@jc:MQConnectionPoolPropsSpecifies the MQSeries connection pool properties for the MQSeries control.

Syntax@jc:MQConnectionPoolProps

[mqPoolSize="pool size value"]

AttributesThis attribute determines the MQSeries connection pool size.

connectionType

The mqPoolSize is a positive integer greater than 0, representing the MQSeries connection pool size.

@jc:ConnectionPoolTimeout Specifies the MQSeries connection pool timeout in seconds.

@jc :Connec t i onRet rySe t t ings


Syntax@jc:ConnectionPoolTimeout

[conTimeout="connection timeout value in seconds"]

AttributesThis attribute determines the MQSeries connection pool timeout value in seconds.

conTimeoutThe connection timeout value should be a positive integer greater than 0.

@jc:ConnectionRetrySettingsSpecifies the retry settings for the connection to the MQSeries queue manager.

Syntax@jc:ConnectionRetrySettings

[retryCount="connection retry count value"][retryWaitTimeInMilliseconds="wait time in milliseconds between each retry"]

AttributesThese attributes determine the retry setting values for the connection.

retryCountThe retry count should be a positive integer value representing the number of times the MQSeries control attempts to establish a connection to the MQSeries queue manager.

retryWaitTimeInMillisecondsThe interval, in milliseconds, that the MQSeries control waits between each attempt to establish a connection to the MQSeries queue manager.

@jc:MQQueueManagerSpecifies the name of the queue manager for connection.

Syntax@jc:MQQueueManager

[queueManager="queue manager name"]



AttributesThis attribute determines the MQSeries queue manager to which connection is to be obtained.

queueManagerThe queue manager name should be a String value, representing the queue manager to which connection is to be obtained.

@jc:MQAuthorization Specifies the MQSeries authorization property for the MQSeries control.

Syntax@jc:MQAuthorization

[requireAuthorization="Yes|No"]

AttributesThis attribute determines whether MQSeries authorization is required or not.

requireAuthorizationThe requireAuthorization attribute value should be either Yes or No.

@jc:TCPSettingsSpecifies the TCP connection settings for the MQSeries control.

Syntax@jc:TCPSettings

[host="host name"][port="port number"][channel="server connection channel name"][ccsid="Coded Character Set Id"][user="User name"] [password="Password"] [sendExit="Send Exit class name"][receiveExit="Receive Exit class name"] [securityExit="Security Exit class name"]

@jc:SSLSe t t ings


AttributesThese attributes determine the TCP connection settings while connecting to the queue manager using the TCP connection mode.

host This represents the host name of the machine where the queue manager is running.

portThis represents the port number of the queue manager.

channelThis represents the server connection channel of the queue manager through which the connection is to be obtained.

ccsidThis represents the Coded Character Set Id to be used while connecting to the queue manager.

userThis represents the user who is connecting to the queue manager.

passwordThis represents the password of the user connecting to the queue manager.

sendExitThis represents the fully qualified name of the class implementing the MQSeries MQSendExit interface.

receiveExitThis represents the fully qualified name of the class implementing the MQSeries MQReceiveExit interface.

securityExitThis represents the fully qualified name of the class implementing the MQSeries MQSecurityExit interface.

@jc:SSLSettings Specifies the SSL settings for the MQSeries control.



Syntax@jc:SSLSettings

[sslRequired="true / false"][twoWaySSLRequired="true / false"]

AttributesThese attributes represent the SSL settings for the MQSeries control when TCP connection mode is selected.

sslRequiredThis attribute determines if SSL is required or not, based on whether the value is True or False.

twoWaySSLRequiredThis attribute determines if two-way SSL is required or not, based on whether the value is True or False.

@jc:DefaultQueue Specifies the default queue name to be used for sending and retrieving messages.

Syntax@jc:DefaultQueue

[defaultQueueName="name of the default queue"]

AttributeThis attribute determines the name of the default queue to be used for sending and retrieving messages.

defaultQueueNameThe default queue name attribute value should be a String value representing a valid MQSeries queue name present in the queue manager to which connection is to be obtained.

@jc : Impl ic i t Transac t i on


@jc:ImplicitTransactionSpecifies the transaction mode of the MQSeries control.

Syntax@jc:ImplicitTransaction

[implicitTransactionRequired="true|false"]

AttributesThis attribute determines whether the implicit transaction mode is required or not, while sending and receiving messages.

implicitTransactionRequired

The implicit transaction required attribute value can be either True or False.

C H A P T E R 13

Process Control Annotations

This section describes the process control annotations.

The Process control extends WebLogic Workshop controls and uses some of the same annotations. For more information, see the following annotations:

@common:message-buffer Annotation

@jc:conversation Annotation

@jc:location Annotation

Related TopicsProcess Control


http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/message-buffer.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/conversation.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/location.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsProcess.html

Process Cont ro l Anno ta t i ons


C H A P T E R 14

RosettaNet Control Annotations

This section describes the RosettaNet control annotation.

@jc:rosettanet Annotation

@jc:rosettanet Annotation Specifies the JCX class-level annotations for the RosettaNet control.

Note: Annotations can be specified at the JCX class level, at the JCX instance level, and at the JCX method level, in increasing order of precedence.

Syntaxjc:rosettanet

[from="initiatorID"] | [from-selector="{xquery-expression}"][to="participantID"] | [to-selector="{xquery-expression}"][="rnif-version"][="pip"][="pip-version"][="from-role"][="to-role"]


Rose t taNe t Cont ro l Anno ta t ions

AttributesThe following attributes specify class- and method-level configuration attributes for the RosettaNet control:

fromDUNS of the initiator. Must match the business ID for the trading partner as defined in the TPM repository.

from-selectorXQuery expression that selects the business ID of the initiator. To learn how to specify the initiator business ID dynamically, see "Dynamically Specifying Business IDs" in Using a RosettaNet Control.

Note: This attribute is not available at the control type level in the control definition file (JCX file). It only applies to control instance declarations in the business process file (JPD file).

toDUNS of the participant. Must match the business ID for the trading partner as defined in the TPM repository.

to-selectorXQuery expression that selects the business ID of the participant. To learn how to specify the recipient business ID dynamically, see "Dynamically Specifying Business IDs" in Using a RosettaNet Control.

Note: This attribute is not available at the control type level in the control definition file (JCX file). It only applies to control instance declarations in the business process file (JPD file).

rnif-versionVersion of the RosettaNet Implementation Framework. Must be either 1.1 or 2.0.

pipRosettaNet PIP code, such as 3B2. Must be a valid PIP code as defined in http://www.rosettanet.org.

pip-versionRosettaNet PIP version. Must be a valid version number associated with the PIP.


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsRosettaNetUse.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsRosettaNetUse.html

@jc : rose t tane t Anno ta t i on

from-roleRosettaNet role name for the sender as defined in the PIP specification, such as Buyer, Seller, Supplier, Receiver, Shipper, and so on. A PIP request might be rejected if an incorrect value is specified.

to-roleRosettaNet role name for the recipient as defined in the PIP specification, such as Buyer, Seller, Supplier, Receiver, Shipper, and so on. A PIP request might be rejected if an incorrect value is specified.


Rose t taNe t Cont ro l Anno ta t ions


C H A P T E R 15

Service Broker Control Annotations

This section describes the service control annotations.

The Service Broker control extends WebLogic Workshop controls and uses some of the same tags and annotations. For more information, see the following annotations:

@common:define Annotation

@jc:conversation Annotation

@jc:location Annotation

@jc:wsdl Annotation

Related TopicsService Broker Control


http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/define.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/conversation.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/location.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jc/wsdl.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsService.html

Serv ice B roke r Cont ro l Annota t i ons


C H A P T E R 16

Worklist Control Annotations

This section includes information on Task control and Task Worker control annotations.

These annotations along with their attributes determine the default behavior of the Worklist controls. The Task and Task Worker controls may be configured during their lifetimes by calling methods in the TaskControl and TaskWorkerControl classes. The information contained in the annotations include the following:

The object type that you must create to pass or return from methods at run time.

The object type on which you must base the formatting of the text or the specified java.lang.String value you provide.

All worklist annotation tags can receive string values in the format of the relevant object type.

Some annotations accept enumerations, limited to a choice of defined values.

Each annotation specifies which Task or Task Worker control it uses.

Values that may be arrays show the base class with a suffix of [], for example, String[].

Topics Included in This Section@jc: advanced Annotation

Notations for advanced options.

@jc:assignee AnnotationAssigns user and groups to Tasks.


Work l is t Cont ro l Anno ta t ions

@jc:select AnnotationAccepts values to search for Tasks, including TaskSelector objects, and returns a set of Task IDs.

@jc:task AnnotationAssigns a Task to the Assignees List.

@jc:task-abort AnnotationChange the state of a task to ABORTED.

@jc:task-assign AnnotationAssigns a Task to the Assignees List.

@jc:task-claim AnnotationSets a default user as having put a Task in a claimed state, as a claimant.

@jc:task-complete AnnotationCreates Worklist control methods that place Tasks in a completed state.

@jc:task-create AnnotationCreates Tasks.

@jc:task-delete AnnotationCreates Worklist control methods that delete Tasks.

@jc:task-event AnnotationProvides Task information for implementing callback method interfaces.

@jc:task-get-info AnnotationCreates Worklist control methods that return information from Tasks.

@jc:task-get-property AnnotationCreates methods that return the value of a Task property as a String.

@jc:task-get-property-name AnnotationCreates Worklist control methods that return Task property names.

@jc:task-get-request AnnotationCreates Worklist control methods that return Task request data.

@jc:task-get-response AnnotationCreates Worklist control methods that return Task response data.

@jc:task-remove-property AnnotationRemove properties with the name you specify from Tasks.


@jc : advanced Annota t i on

@jc:task-resume AnnotationCreates Worklist control methods that remove Tasks from a suspended state.

@jc:task-return AnnotationCreate Worklist control methods that place Tasks in an assigned state using the original Assignees List.

@jc:task-set-property AnnotationSets the value of a single Task property.

@jc:task-start AnnotationCreates Worklist control methods that place Tasks in a started state.

@jc:task-stop AnnotationCreates Worklist control methods that change Tasks from started to claimed states.

@jc:task-suspend AnnotationCreates Worklist control methods that place Tasks in a suspended state.

@jc:task-update AnnotationUpdates one or more Task properties at a time for a method.

@jc:task-worker AnnotationSpecifies that the control is a Task Worker control.

Related TopicsTaskControl Interface

Worklist Controls

@jc: advanced AnnotationNotations for advanced options.

Used by the Task control.

Syntaxajc:advanced

[can-be-reassigned="true|false"][can-be-returned="true|false"][can-be-aborted="true|false">][claim-due-business-date="the business due date"][completion-due-business-date="the completion business due date"]


http://e-docs.bea.com/workshop/docs81/doc/en/integration/java-class/com/bea/control/TaskControl.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/controls/controlsWorklist.html


[completion-user-calendar="the user completion due date calendar"][claim-user-calendar="the user claim due date calendar"][completion-calendar="the completion due date calendar"][claim-calendar="the claim due date calendar"]

Attributescan-be-reassigned

A Boolean that determines whether the Task can be reassigned to a different Assignees List. If the value is set to true, the Task can be reassigned. If the value is set to false, the Task cannot be reassigned by the assignee or claimant of the Task.

can-be-returnedA Boolean that determines whether the Task can be returned to an assigned state, which specifies the users who are allowed to become the claimant. If the value is set to true, a Task can be returned to an assigned state. If the value is set to false, the Task cannot be returned by the assignee or claimant of the Task.

can-be-abortedA Boolean that determines whether a Task can be aborted. If the value is set to true, a Task can be aborted. If the value is set to false, the Task cannot be aborted by the assignee or claimant of the Task.

claim-due-business-dateA string that sets due date for a Task to be claimed, using a business time duration.

completion-due-business-dateA string for setting the business duration that a Task is due to be completed.

completion-user-calendarA string that directs a Task to use the calendar of the user whose name you specify for the completion date.

claim-user-calendarA string that directs the Task to use the calendar of the user whose name you specify for the claim due date.

completion-calendarA string that sets the calendar for the date that a Task is due to be completed.

claim-calendarA string that indicates which business calendar to use for setting the date that a Task should be in a claimed state.


@jc :ass ignee Annota t i on

@jc:assignee AnnotationAssigns user and groups to Tasks.


Syntax@jc:assignee

[user="user1,user2,user3,...,userN"][group="group1,group2,group3,...,groupN"][algorithm=["ToUser" | "ToUserInGroup" | "ToUsersAndGroups"]

Attributesuser

A string or string array. This setting consists of one or more user names for the Assignees List. You must separate each group name with a comma.

groupA string or string array. This annotation consists one or more group names for the Assignees List. You must separate each group name with a comma.

algorithmA string for determining how to assign Tasks from users on the Assignees List. It must be one of the following values:ToUser—assigns the Task to a user by name.ToUserInGroup—assigns the Task to the user in the group that has the least work to perform.ToUsersAndGroups—assigns the Task to any list of users, list of groups, or combination of users and groups.

@jc:select AnnotationAccepts values to search for Tasks, including TaskSelector objects, and returns a set of Task IDs.

Used by the Task Worker control.



Syntax@jc:select

[assigned-group="group(s) for assignee list"][assigned-user="user(s) for assignee list"][claimant="the claimant user"][claim-due-date-after="search for Tasks with claim due dates after this value"[claim-due-date-before="search for Tasks with claim due dates before this value"[comment="the Task comment"][completion-due-date-after="search for Tasks with completion due dates after this value"][completion-due-date-before="search for Tasks with completion due dates before this value"][creation-date-after="search for Tasks with creation dates after this value"][creation-date-before="search for Tasks with creatoin dates before this value"][max-priority="return Tasks with priorities less than or equal to this value"][min-priority="return Tasks with priorities greater than or equal to this value"][owner="search by Task owner"][property-name="search by property name"][property-value="search by the value of the setting for property-name"][selector="a TaskSelector object to use for searching Tasks"][states="search by Task state"][task-id="search by Task ID"]

Attributesassigned-group

A string or string array (string []) that specifies a search by groups on the Assignees List for a Task.

assigned-userA string or string array (string []) that specifies a search by users on the Assignees List for a Task.

claimantA string or string array (string []) that specifies a search by the claimant for a Task.


@jc :se lec t Anno ta t i on

claim-due-date-afterSpecifies a search by Tasks with a due date after the value you provide (java.lang.Date).

claim-due-date-before Specifies a search by Tasks with a claim due date before the value you provide (java.lang.Date).

commentA string that specifies a search by Task comments.

completion-due-date-afterSpecifies a search by Tasks with a completion due date after the value you provide (java.lang.Date).

completion-due-date-beforeSpecifies a search by Tasks with a completion due date before the value you provide (java.lang.Date).

creation-date-afterSpecifies a search by Tasks with a creation date after the value you provide (java.lang.Date).

creation-date-beforeSpecifies a search by Tasks with a creation date before the value you provide (java.lang.Date).

max-prioritySpecifies a search by Tasks with no greater priority than the value you provide (java.lang.Long).

min-prioritySpecifies a search by Tasks with no lesser priority of the value you provide (java.lang.Long).

ownerA string or string array (string []) that specifies a search by the Task owner.

property-nameA string that specifies a search by Tasks with a given property.

property-valueA string that specifies a search by Tasks with a given value for the property defined by property-name.

selectorA TaskSelector that specifies a search by the configuration of the TaskSelector object you provide for this value.



statesSpecifies searching of Tasks by state. Values can be as follows:

A string or string array of valid state types, such as completed or assigned.

An integer or integer array representation of state types (java.lang.Long).

A com.bea.wli.worklist.api.StateType or StateType array.

task-idA string or string array (string []) that specifies a search by the unique Task ID.

@jc:task AnnotationAssigns a Task to the Assignees List.


Syntax@jc:task

[name="task name"][owner="task owner user"][description="task description"]

Attributesname

A string specifying the Task name displayed in WebLogic Workshop.

ownerA string specifying the name of the Task owner.

descriptionA string for describing a Task to provide information.


@jc: task-abor t Anno ta t i on

@jc:task-abort AnnotationChange the state of a task to ABORTED.

Used by the Task and Task Worker controls.

Syntax@jc:task-abort

[enabled="true"]

Attributesenabled

When set to true, this Boolean creates Worklist control methods that place Tasks in an aborted state.

@jc:task-assign AnnotationAssigns a Task to the Assignees List.

Used by Task and Task Worker controls.

Syntax@jc:task-assign

[user="user1,user2,user3,...,userN"][group="group1,group2,group3,...,groupN"][algorithm=["ToUser" | "ToUserInGroup" | "ToUsersAndGroups"]

Attributesuser

A string or string array. This setting consists of one or more user names for the Assignees List. You must separate each group name with a comma.

groupA string or string array. This annotation consists one or more group names for the Assignees List. You must separate each group name with a comma.

algorithmA string for determining how to assign or claim Tasks from users on the Assignees List. It must be one of the following values:



ToUser—claims the Task to a user by name.ToUserInGroup—assigns the Task to the user in the group that has the least work to perform.ToUsersAndGroups—assigns the Task to any list of users, list of groups, or combination of users and groups.

@jc:task-claim AnnotationSets a default user as having put a Task in a claimed state, as a claimant.


Syntax@jc:task-claim

[enabled="true"][claimant="user"]

Attributesenabled

When set to true, this Boolean creates Worklist control methods that place Tasks in a claimed state.

claimantA string that specifies the name of the claimant user.

@jc:task-complete AnnotationCreates Worklist control methods that place Tasks in a completed state.

Used by the Task Worker Control.

Syntax@jc:task-complete

[enabled="true"]


@jc : task-crea te Anno ta t i on

Attributesenabled

When set to true, this Boolean creates Worklist control methods that place Tasks in a completed state.

@jc:task-create AnnotationCreates Tasks.


Syntax@jc:task-create

[name="the Task name"][description="task description"][comment="the text of a comment"][request-mime-type="the mime type of the request"][request=the data of the request][priority="an integer for priority"][owner="the new task owner"][can-be-reassigned="true|false"][can-be-aborted="true|false">][can-be-returned="true|false"][claim-due-business-date="the business due date"][claim-due-date="the claim due date"][completion-user-calendar="the user completion due date calendar"][completion-calendar="the completion due date calendar"][claim-user-calendar="the user claim due date calendar"][claim-calendar="the claim due date calendar"][completion-due-date="the completion due date"][completion-due-business-date="the completion business due date"]

Attributesname

A string specifying the Task name displayed in WebLogic Workshop.

descriptionA string for describing a Task to provide information.

commentA string for setting for comments about the Task.



request-mime-typeA string that specifies the mime type of the request data. This annotation exists for information purposes only and does not provide any handling of data or validation.

requestThe data of the Task request. Can be any type or format that can accept any serializable Java object that is imported and accessible to your control.

priorityThis integer sets the magnitude of the priority of the Task. The default is 1.

ownerA string specifying the name of the Task owner.

can-be-reassignedA Boolean that determines whether the Task can be reassigned to a different Assignees List. If the value is set to true, the Task can be reassigned. If the value is set to false, the Task cannot be reassigned by the assignee or claimant of the Task.

can-be-abortedA Boolean that determines whether a Task can be aborted. If the value is set to true, a Task can be aborted. If the value is set to false, the Task cannot be aborted by the assignee or claimant of the Task.

can-be-returnedA Boolean that determines whether the Task can be returned to an assigned state, which specifies the users who are allowed to become the claimant. If the value is set to true, a Task can be returned to an assigned state. If the value is set to false, the Task cannot be returned by the assignee or claimant of the Task.

claim-due-business-dateA string that sets due date for a Task to be claimed, using a business time duration.

claim-due-dateSets the date that a Task is due to be in a claimed state (java.lang.Date).

completion-user-calendarA string that directs a Task to use the calendar of the user whose name you specify for the completion date.

completion-calendarA string that sets the calendar for the date that a Task is due to be completed.


@jc : task-dele te Anno ta t i on

claim-user-calendarA string that directs the Task to use the calendar of the user whose name you specify for the claim due date.

claim-calendarA string that indicates which business calendar to use for setting the date that a Task should be in a claimed state.

completion-due-dateSets the date that a Task is due to be completed (java.lang.Date).

completion-due-business-dateA string for setting the business duration that a Task is due to be completed.

@jc:task-delete AnnotationCreates Worklist control methods that delete Tasks.


Syntax@jc:task-delete

[enabled="true"]

Attributesenabled

When set to true, this Boolean creates a Worklist control method for deleting Tasks.

@jc:task-event AnnotationProvides Task information for implementing callback method interfaces.


Syntax@jc:task-event

event-type="["abort" |"assign"|"claim"|"claimExpire"|"complete"|"create" |"expire" |"resume"|"return"|"start"|"stop"|"suspend"]"[response="the Task response data"]



[time="the time of the event"][user="the user who changed the Task state"]

Attributesevent-type

A string (enumeration) that specifies the possible events that can trigger a callback method. It must be one of the following values:abortassignclaimclaimExpirecompletecreateexpireresumereturnstartstopsuspend

responseA parameter for the response data of the Task. Can be any type or format that can accept any serializable Java object that is imported and accessible to your control.

timeSpecifies text in java.lang.Date format that represents the time of the event listed for the event-type.

userA string that specifies the active user who triggers the event listed for the event-type.

@jc:task-get-info AnnotationCreates Worklist control methods that return information from Tasks.


Syntax@jc:task-get-info

[enabled="true"]


@jc : task-get - in fo Anno ta t i on

Attributesenabled

When set to true, this Boolean creates Worklist control methods that return information from Tasks.

RemarksMethods in the Task Worker control with this annotation can have the following return types:

String, String[]

TaskInfo, TaskInfo[]

TaskInfoXML, TaskInfoXML[]

The jc:task-get-info annotation is used in correlation with @jc:task-get-info.

The return type determines the value returned by the method:

String → the taskId

TaskInfo → the TaskInfo object

TaskInfoXML → the taskInfoXML

If you need to select more than one Task with @jc:task-get-info, use an array instead. If you specify a return type for a single task and multiple tasks are selected, a run-time exception occurs when the code executes. If you are unsure, it is better to return an array, as shown in the following example:

/**

* @jc:task-get-info enabled="true"

* @jc:select task-id="{taskId}"

*/

public TaskInfo getTaskInfo(String taskId);

/**

* @jc:task-get-info enabled="true"

* @jc:select task-id="{taskIds}"

*/

public TaskInfoXMLDocument[] getTasksInfoXML(String[] taskIds);



@jc:task-get-property AnnotationCreates methods that return the value of a Task property as a string.


Syntax@jc:task-get-property

[name="the property name"]

Attributesname

Creates methods that return the value of a Task property as a string.

@jc:task-get-property-name AnnotationCreates Worklist control methods that return Task property names.


Syntax@jc:task-get-property-name

[enabled="true"]

Attributesenabled

When set to true, this Boolean creates Worklist control methods that return Task property names.

@jc:task-get-request AnnotationCreates Worklist control methods that return Task request data.


Syntax@jc:task-get-request

[enabled="true"]


@jc : task-get - response Anno ta t i on

Attributesenabled

When set to true, this Boolean creates Worklist control methods that return Task request data.

@jc:task-get-response AnnotationCreates Worklist control methods that return Task response data.


Syntax@jc:task-get-response

[enabled="true"]

Attributesenabled

When set to true, creates Worklist control methods that return Task response data.

@jc:task-remove-property AnnotationRemoves a property with the name you specify from Tasks.


Syntax@jc:task-remove-property

[name="the name of a property to remove"]

Attributesname

A string that removes properties with the name you specify from Tasks.

@jc:task-resume AnnotationCreates Worklist control methods that remove Tasks from a suspended state.



Used by the Task and Task Worker control.

Syntax@jc:task-resume

[enabled="true"]

Attributesenabled

When this Boolean is set to true, creates Worklist control methods that remove Tasks from a suspended state.

@jc:task-return AnnotationCreate Worklist control methods that place Tasks in an assigned state using the original Assignees List.


Syntax@jc:task-return

[enabled="true"]

Attributesenabled

When set to true, this Boolean creates Worklist control methods that place Tasks in an assigned state using the original Assignees List.

@jc:task-set-property AnnotationSets the value of a single Task property. To set the values for more than one property at a time, use @jc:task-update Annotation.



@jc : task-star t Anno ta t i on

Syntax@jc:task-set-property

[name="the name of a property to set"][value="the value to set the property"]

Attributesname

A string that specifies the name of the property.

valueA string that specifies the value to assign the property.

@jc:task-start AnnotationCreates Worklist control methods that place Tasks in a started state.


Syntax@jc:task-start

[enabled="true"]

Attributesenabled

When set to true, this Boolean creates Worklist control methods that place Tasks in a started state.

@jc:task-stop AnnotationCreates Worklist control methods that change Tasks from started to claimed states.


Syntax@jc:task-stop

[enabled="true"]



Attributesenabled

When set to true, this Boolean creates Worklist control methods that change Tasks from started to claimed states.

@jc:task-suspend AnnotationCreates Worklist control methods that place Tasks in a suspended state.


Syntax@jc:task-suspend

[enabled="true"]

Attributesenabled

When set to true, this Boolean creates Worklist control methods that place Tasks in a suspended state.

@jc:task-update AnnotationUpdates one or more Task properties at a time for a method. It offers the same attributes that are available through the task-create attribute, except that it offers response-related attributes and it does not offer the description attribute.


Syntax@jc:task-update

[comment="the text of a comment"][request-mime-type="the mime type of the request"][request=the data of the request][response-mime-type="the mime type of the response"][response=the data of the response][priority="an integer for priority"][owner="the new task owner"][can-be-reassigned="true|false"][can-be-aborted="true|false">]


@jc: task-worke r Anno ta t i on

[can-be-returned="true|false"][name="the Task name"][claim-due-business-date="the business due date"][claim-due-date="the claim due date"][completion-user-calendar="the user completion due date calendar"][completion-calendar="the completion due date calendar"][claim-user-calendar="the user claim due date calendar"][claim-calendar="the claim due date calendar"][completion-due-date="the completion due date"][completion-due-business-date="the completion business due date"]

AttributesFor a list of other available attributes, see @jc:task-create Annotation.

@jc:task-worker AnnotationSpecifies that the control is a Task Worker control.


Syntax@jc:task-worker

This annotation uses no attributes.


C H A P T E R 17

Business Process Annotations

This section provides reference information for WebLogic Integration business process annotations (@jpd:name_of_annotation). A number of Web Service annotations are also supported in business processes (JPD files). Web Service annotations are of the format @jws:name_of_annotation. This section provides reference to the Web Service annotations supported in JPDs.

Topics Included in This Section@jpd:ebxml Annotation

Specifies settings for participant business processes involved in exchanging ebXML business messages.

@jpd:ebxml-method AnnotationSpecifies settings for methods in participant business processes involved in exchanging ebXML business messages.

@jpd:mb-static-subscription AnnotationSpecifies the subscription parameters for a business process.

@jpd:process AnnotationSpecifies settings for a business process.

@jpd:rosettanet AnnotationSpecifies settings for participant business processes involved in exchanging RosettaNet business messages.


Bus iness P rocess Annotat ions

@jpd:selector AnnotationPrecedes an XQuery definition in a business process (JPD) file. The XQuery definition can specify the dynamic callback properties for a Client Response node, or in the case of a Process or a Service Broker control, specifies the dynamic selection of subprocesses to call at run time.

@jpd:transform AnnotationAnnotates a WebLogic Integration transformation control instance, which is instantiated automatically at run time.

@jpd:unexpected-message AnnotationSpecifies settings that allow a business process to ignore a message received before the process flow encounters the node at which the message is expected.

@jpd:version AnnotationSpecifies how to invoke sub processes when different versions of the parent process exist.

@jpd:xml-list AnnotationAnnotates business process variable of Untyped XML—XmlObjectList.

@jpd:xquery AnnotationPrecedes the global XQuery definitions in a business process (JPD) file.

@common AnnotationsDescribes the @common annotations supported by WebLogic Integration business processes.

Web Service Features in Business ProcessesDetails Web service features in Business processes and describes the @jws annotations supported by WebLogic Integration business processes.

General PropertiesDescribes a set of general properties that are displayed in the Property Editor for all the nodes in a business process.

Message BufferBuffers client messages.

Method PropertiesDescribes a set of properties that are displayed in the Property Editor for Java methods.

Variable PropertiesSpecifies the properties for business process variables.


@jpd: ebxml Annota t i on

Control PropertiesDisplays the properties for business process controls: Control Send, Control Receive, Control Send with Return.

@jpd:ebxml AnnotationSpecifies annotations for participant business processes involved in exchanging ebXML business messages.

Syntax@jpd:ebxml

protocol-name="ebXML"

ebxml-service-name="serviceName"

ebxml-action-mode="default" | "non-default"

Attributesprotocol-name

The protocol name, which is always ebXML.

ebxml-service-nameThe name of the ebXML service associated with this business process and defined in the TPM repository. Defaults to the name of the business process file. 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.

Note: This service name corresponds to the eb:Service entry in the ebXML message envelope.

ebxml-action-modeAction 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. 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 one-way conversations, this name must match the method name of the Client Request node in



the corresponding participant business process. For round trip conversations, 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.

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

RemarksNone.

Related TopicsebXML Control

WebLogic Workshop Reference

Introducing Trading Partner Integration at http://edocs.bea.com/wli/docs81/tpintro/index.html

@jpd:ebxml-method AnnotationSpecifies settings for methods in participant business processes involved in exchanging business messages via ebXML.

Syntax@jpd:ebxml-method

envelope="{env}"

Attributesenvelope

Represents the message envelope in an incoming ebXML business message. You can rename the default value (env) as long as it matches the name of the parameter specified in the method.

RemarksUse this annotation with the request method in a client request nodes to assign the ebXML envelope of an incoming message.


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsebXML.html


@jpd :mb-s ta t ic -subsc r ip t i on Annota t i on

ExampleThe following example code shows an implementation of request in a participant business process that retrieves the ebXML envelope from a business message.

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

Related Topics

ebXML Control



@jpd:mb-static-subscription AnnotationSpecifies the subscription parameters for a business process that is started as the result of receiving a message from a Message Broker channel to which the process is subscribed.

Business processes are started by messages. The first activity in a business process (that is, the first child of the <process> tag) must be either a Client Request node or an Event Choice node. When the client invokes this operation, an instance of the business process is started.

A special case of message-started processes is when the Message Broker starts the process as a result of a subscription to a Message Broker channel. The subscription parameters are defined by annotating the starting clientRequest method to indicate that this process is invoked by the Message Broker when it delivers the message.

See Note About Static and Dynamic Subscriptions.

Syntax@jpd:mb-static-subscription

channel-name="/prefix/xxxx/Name"[xquery="xquery"]


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsebXML.html



[filter-value-match="myvalue"][message-metadata="{x1}"] [message-body="{x0}"]


Required. The name of the Message Broker channel to which the business process subscribes. Channel files (filename.channel) define the Message Broker channels available in a WebLogic Integration application. Channel files must be placed in a Schemas project in your application. To learn how to create Message Broker channels, see How Do I: Create Message Broker Channels?

xquery

Optional. Specifies the xquery to use for filtering. Element variables are named by Filter-body and Filter-header. The element variables are named by the message-body and message-metadata attributes.

filter-value-match

Optional string constant. (Required if xquery is specified.) The value of the filter-value-match attribute is compared against the results of the xquery.

message-metadata

Optional string constant. This attribute maps a named parameter in the xquery to the SOAP headers of an incoming message.

message-body

Optional string constant. This attribute maps a named parameter in the xquery to the XML body of an incoming message.

Note About Static and Dynamic SubscriptionsThere are two categories of subscriptions to a Message Broker channel for WebLogic Integration business processes:

You can create an instance of a Message Broker Subscription control and design the subscription to a Message Broker channel using the control.

For the special case of a process that is started as a result of a subscription to a Message Broker channel, you design the subscription on the process’ Start node. (See How Do I: Subscribe to Message Broker Channels?)


http://edocs.bea.com/workshop/docs81/doc/en/integration/howdoI/howChannel.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/howdoI/howSub.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/howdoI/howSub.html

@jpd :pr ocess Anno ta t i on

Subscriptions on a Start node in a business process are called static subscriptions because WebLogic Integration is aware of the subscription when the business process (JPD) is deployed. At deployment time, WebLogic Integration updates its in-memory tables with the subscription information. Tables remain updated until the business process is undeployed.

Subscriptions to Message Broker channels that are defined at a Control node, which communicates with a Message Broker Subscription control, are called dynamic subscriptions. This means that WebLogic Integration is not aware of the subscription when the business process (JPD) is deployed (because the subscription is embedded in the JPD code). When the Message Broker Subscription control node is executed at run time, WebLogic Integration update the tables with the subscription information. The dynamic part for dynamic subscriptions refers to:

The subscription state (subscribed or not)

The filter value for the filter expression

Related TopicsMessage Broker Control Annotations

Subscription Start (Asynchronous)

Subscription Start (Synchronous)

Event Choice Start

How Do I: Create Message Broker Channels?

@jpd:process AnnotationContains the process logic settings for a business process.

Syntax@jpd:process [binding="webservice | ebxml | rosettanet"] process::

<process name="processname" [freezeOnFailure="true | false”] [onSyncFailure="rethrow | rollback"] [retryCount="<count>"] [retryDelay="<delay>"]>

Note: See also the stateless attribute in the following section.


http://e-docs.bea.com/workshop/docs81/doc/en/integration/javadoc-tag/jc/jcBroker.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideStartSub.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideStartSyncSub.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideStartEvChoice.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/howdoI/howChannel.html


Attributesbinding

This property specifies whether the business process uses the Web service, ebXML, or RosettaNet protocol. The default value is webservice. If your business process is an ebXML or a RosettaNet process, select ebxml or rosettanet. In keeping with your selection in the Property Editor, an attribute is written to the @jpd: process annotation in the source code. For example:

@jpd:process binding="rosettanet" process::

To learn about ebXML and RosettaNet business processes, see Building ebXML Participant Business Processes and Building RosettaNet Participant Business Processes.

nameThis is the name of your business process, which is displayed throughout the WebLogic Workshop application, including the WebLogic Integration Administration Console. You can change the name by clicking on this property in the Property Editor and entering a new name.

freeze on failureWhen a business process fails and there is no exception handler configured to handle the exception thrown, the business process is placed into an aborted state and no recovery is possible. However, if the business process is configured to freeze on failure, the business process rolls back to the last commit point and the state is persisted if it fails. The process can then be restarted from the WebLogic Integration Administration Console. To configure a business process to freeze on failure: select true from the freeze on failure drop-down menu.

To learn how to unfreeze business processes in the WebLogic Integration Administration Console, see Process Instance Monitoring in Managing WebLogic Integration Solutions at http://edocs.bea.com/wli/docs81/manage/processmonitoring.html.

on sync failureThis property only applies to your process if it is configured to be a synchronous subprocess; it is ignored for any other business processes. If a synchronous subprocess fails, the default behavior is to mark it as rollback, which causes both the subprocess and the parent process to rollback. However, if the on sync failure property is set to rethrow, only the subprocess is rolled back. To learn more about synchronous subprocesses and the on sync failure property, see “Working with Subprocesses” in Building Synchronous and Asynchronous Business Processes.


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideEbXML.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideEbXML.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideRosettaNet.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideSync.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideSync.html

@jpd : rose t tane t Annota t i on

retry countSpecify how many times, after the first attempt, the process engine should try to execute the business process.

If your business process contains an asynchronous client request node or multiple client request nodes, any one of which is asynchronous, then you can set the retry count for the business process. You cannot set the retry count property for business processes that contain only synchronous client request nodes (that is, Client Request with Return nodes).

retry delaySpecify the amount of time (in seconds) you want to pass before a retry is attempted.

If your business process contains an asynchronous client request node or multiple client request nodes, any one of which is asynchronous, then you can set the retry delay for the business process. You cannot set the retry delay property for business processes that contain only synchronous client request nodes (that is, Client Request with Return nodes).

statelessThis property is read only; it cannot be edited. It specifies whether your business process is stateless (property displays true) or stateful (property displays false). To learn more about stateless and stateful business processes, see Building Stateless and Stateful Business Processes.

@jpd:rosettanet AnnotationSpecifies settings for participant business processes involved in exchanging RosettaNet business messages.

Syntax@jpd:rosettanet

protocol-name="rosettanet"

protocol-version="1.1" | "2.0"

pip-name="pipName"

pip-version="pipVersion"

pip-role="pipRole"


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideState.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideState.html


Attributesprotocol-name

The protocol name, which is always rosettanet.

protocol-versionRNIF (RosettaNet Implementation Framework) version. One of the following values:- 1.1- 2.0

pip-nameRosettaNet PIP code, such as 3B2. Must be a valid PIP code as defined in http://www.rosettanet.org.

pip-versionRosettaNet PIP version. Must be a valid version number associated with the PIP.

pip-roleRosettaNet role name for the recipient as defined in the PIP specification, such as Seller, Supplier, Shipper, and so on. A PIP request might be rejected if an incorrect value is specified.

RemarksNone.

Related TopicsRosettaNet Control



@jpd:selector AnnotationThe @jpd:selector annotation precedes an XQuery definition in a business process (JPD) file. The XQuery definition can specify the dynamic callback properties for a Client Response node, or in the case of a Process or a Service Broker control, the XQuery allows dynamic selection of subprocesses at run time. In other words, configuration of the business process at run time allows one of multiple subprocesses to be called.


http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsRosettaNet.html


@jpd: t ransform Annota t i on

Syntax@jpd:selector xquery::

RemarksThe XQuery definition can specify the dynamic callback properties for a Client Response node, or in the case of a Process or a Service Broker control, the XQuery allows dynamic selection of subprocesses at run time.

For a Process control or a Service Broker control, the dynamic selector allows you to configure a lookup property based on a LookupControl or TPM function. You can then configure your business process in the WebLogic Integration Administration Console such that at run time, the security of the callback to the client is handled differently, based on the value of the lookup property that you specified in the dynamic selector.

To learn about adding dynamic callback properties for Client Response nodes in a business process, see “Adding Dynamic Callback Properties” in Sending Messages to Clients.

To design a dynamic selector for a Process control, see Editing and Testing a Dynamic Selector.

To design a dynamic selector for a Service Broker control, see Editing and Testing a Dynamic Selector.

@jpd:transform AnnotationThe @jpd:transform annotation annotates a WebLogic Integration data transformation control instance, which is instantiated automatically at run time.

Syntax@jpd:transform

RemarksNone.

Related TopicsGuide to Data Transformation

Tutorial: Building Your First Data Transformation


http://edocs.bea.com/workshop/docs81/doc/en/workshop/dtguide/dtguideIntro.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/dttutorial/tutWLIDataTransIntro.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideClientsCallbackNode.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsProcessEditSelect.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsServiceEditSelect.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsServiceEditSelect.html


Adding Instances of Controls to Your Business Process Project

@jpd:unexpected-message AnnotationAllows a business process to ignore messages received by a business process for a Control Receive node or a Client Request node (in positions in the business process other than at the Start node) before the process flow encounters the node at which the message is expected.

Syntax@jpd:unexpected-message

action = "save | discard"

Attributesaction

Specifies the action to be taken for messages that are received by a business process before the process flow encounters the node at which the message is expected. Possible values are save (the default) and discard.

RemarksBusiness processes can include Control Receive or Client Request nodes, at which the process flow waits at run time for delivery of a message before continuing. By default, messages that arrive before they are expected—that is, before the business process encounters the Control Receive or Client Request node in the process flow—are buffered and are delivered when the process is ready to receive them (that is, when the Control Receive or Client Request node is encountered). You can design your process such that any such unexpected (early) messages are discarded. This enables the Control Receive and Client Request nodes to ignore messages that arrived and were buffered by the business process, but that are no longer relevant to the process. The jpd:unexpected-message annotation is available for Control Receive nodes and Client Request nodes in positions other than the Start node. This annotation gives you the ability to control this behavior on a node-by-node basis at design time.

To Specify the jpd:unexpected-message Annotation

1. Switch your view of the business process to the Source View.

2. Click on the Control Receive or Client Request node’s method header. The Property Editor displays the unexpected-message property. Note that the action attribute is specified as the default value: save.


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideControlsInstance.html

@j pd :ver s i on Anno ta t i on

3. In the Property Editor, change the specification from save to discard. The annotation is written into the JPD source code, immediately preceding the method header:

/** * @jpd:unexpected-message action="discard" */

Related TopicsInteracting With Clients

Interacting With Resources Using Controls

@jpd:version AnnotationSpecifies how to invoke sub processes when different versions of the parent process exist.

Syntax@jpd:version

strategy="loosely-coupled |tightly-coupled"

Attributesloosely-coupled

Select loosely-coupled if you want the subprocess version to be set at the time that the sub process is invoked.

tightly-coupledSelect tightly-coupled if you want the subprocess version to be set at the time the parent process is invoked.

RemarksWhen a business process is displayed in the Design View or the Source View, the Property Editor displays the version property. By default the strategy is specified as loosely coupled. You can change the specification from the strategy drop-down menu in the Property Editor. The annotation is written into the JPD source code—for example:

::

* @jpd:version strategy="loosely-coupled"

*/


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideClients.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideControls.html


Related TopicsVersioning Business Processes

@jpd:xml-list AnnotationThe @jpd:xml-list annotation annotates business process variables of Untyped XML, specifically variables of type XmlObjectList.

Syntax@jpd:xml-list

RemarksAn XMLObjectList data type represents a sequence of untyped XML format data. In other words, this data type represents a sequence of XML elements (a set of repeating elements) that is not valid against an XML Schema.

Related TopicsBusiness Process Variables and Data Types

For an example of working with XmlObjectList data types, see Step 9. Create Quote Document in the Tutorial: Building Your First Business Process.

@jpd:xquery AnnotationPrecedes the global XQuery definitions in a business process (JPD) file. The definitions are in scope for all XQueries in the business process. Namespaces are declared in the xquery prologue.

Syntax@jpd:xquery prologue ::

xquery_namespaces_and_function_definitions ::

Where xquery_namespaces_and_function_definitions represents the XQuery namespaces and function definitions specified in the annotation.


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideDataTypes.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/tutorial/tutWLIProcessXformJoin.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/tutorial/tutWLIProcessIntro.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideVersion.html

@common Annotat ions

RemarksIn WebLogic Workshop, expand the region of code labeled /** Process Language*/ in the Source View for a business process (JPD) to see the Java code that describes the business process you created in the Design View. XQuery statements are written to the JPD file in this region.

The XQuery statements are preceded by the following annotation:

@jpd:xquery prologue::

For example, when you select a repeating XML node using the For Each node builder, as described in Designing For Each Nodes, an XQuery expression is created in your JPD file. The expression returns the set of XML elements over which the For Each node iterates. XQuery expressions are also written in your JPD file when you create conditions on Decision nodes. XQuery expressions also define the transformations you create between disparate data types using the mapping tool.

Related TopicsTo learn about XQueries, see XQuery Reference.

To learn about For Each nodes and Decision nodes, see the following topics:

Looping Through Items in a List

Defining Conditions For Branching

To learn data transformations, see the following topics:

Guide to Data Transformations


@common AnnotationsCommon annotations (those annotations available to more than one type of file in WebLogic Workshop) are also supported in JPD files. They are of the format @common:name_of_annotation.

The following links provide reference to the common annotations used in business processes:


http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/refXQuery/refXQueryIntro.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguideIntro.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/dttutorial/tutWLIDataTransIntro.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideForEachDesign.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideDecision.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideForEach.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/tags/navCommonAnnotations.html


Web Service Features in Business ProcessesThis section covers some of the unique WebLogic Integration Web service features. The topics covered in this section are:

General Features

@jws (Web Service) Annotations

JwsContext Interface

General FeaturesThis section details how the following features work in conjunction with WebLogic Integration and details whether or not they are supported for WebLogic Integration. The links provide reference to the further information of each feature.

Common Annotationsinclude . . .

@common:control Indicates that the object annotated by this annotation is a WebLogic Workshop control in a JCX file.

@common:message-buffer Specifies that there should be a queue between the component's implementation code and the message transport wire for the specified method or callback.

@common:security Specifies the security configuration for a class or an individual method within a class.

@common:xmlns Defines an XML namespace prefix for use elsewhere in the component class.

To learn about all the @common annotations, see Common Annotations.

Accessing SOAP Attachments in Web Services

This feature is supported for all operations.

Specifying SOAP Handlers for a Web Service

This feature is only supported for read-only operations. For more information, see @jws:handler in @jws (Web Service) Annotations.


http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/getstarted/conSOAPHandlers.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/getstarted/conUsingSOAPAttachments.html


http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/control.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/message-buffer.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/security.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/xmlns.html


Web Se rv ice Features in Busi ness P rocesses

Generating SOAP Faults from a Web Service

This feature is supported for synchronous operations, but not for asynchronous operations.

Note: For a SOAP fault to be returned to the JPD client, you must throw com.bea.jws.SoapFaultException instead of javax.xml.rpc.soap.SOAPFaultException. For more information, see SoapFaultException Class.

Much like the Service control, the Service Broker control can throw a ServiceControlException class when a SOAP fault occurs. To access this SOAP fault, use the JPD's JpdContext.ExceptionInfo interface to see if the offending cause is a ServiceControlException. For more information on the ServiceControlException class, see “ServiceControlException Class” in com.bea.control Package. For more information on the JpdContext.ExceptionInfo interface, see “JpdContext.ExceptionInfo Interface” in com.bea.jpd Package.

This feature can also be used to validate XML Schemas. For more information, see Validating Schemas.

WSDL Generation This feature is generally supported for all operations. For more information on WSDL binding, see @jws:protocol in @jws (Web Service) Annotations.

Versioning Web Services This feature is supported for all operations.

Supported Message Formats It is recommended that supported message formats are carefully selected. For more information, see @jws:protocol in @jws (Web Service) Annotations.

Conversing with Non-WebLogic Workshop Clients

Use the SOAP <startheader>, <continueheader>, and <callbackheader> at your own risk.

Transport Security This feature is supported for all operations.

Web Service Security This feature is not supported for any operations. For more information, see @jws:ws-security in @jws (Web Service) Annotations.

Role-Based Security This feature is supported for all operations.

Non-XML and non-primitive Java classes in WSDL

This feature is not supported for any operations.

XQuery Maps When creating XQuery maps, you should always set the protocol before mapping. You should also be aware that http-soap=”true” generates different maps than when http-soap=”false”.


http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/progmodel/conGeneratingSoapFaults.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/java-class/com/bea/jws/SoapFaultException.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideSchemas.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/java-class/com/bea/jpd/package-summary.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/java-class/com/bea/control/package-summary.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/devenv/conWsdlFiles.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/devenv/conVersioningWebServices.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/progmodel/conSupportedMessageFormats.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/converse/conConversingwithNon-WorkshopClientsandServices.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/security/transport/ovwTransportSecurity.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/security/ws-security/ovwWebServiceSecurity.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/security/role-based/navRoleBasedSecurity.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideDataTypesWorking.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/xquerymap/conIntroductionToXQueryMaps.html


@jws (Web Service) AnnotationsA number of Web Service annotations are supported in WebLogic Integration business processes (JPD files). Web Service annotations are of the format @jws:name_of_annotation.

The following links provide reference to the Web Service annotations used in business processes:

Java Web Service Annotationsinclude . . .

@jws:conversation-lifetime Specifies the maximum age and the maximum idle time for a service's conversations.

See also, Managing Conversations.

@jws:handler Specifies SOAP message handlers for a Web service. This annotation is only supported for read-only operations.

Service Broker controls can add JAX-RPC handlers that are invoked before sending messages and before invoking callbacks via the @jws:handler annotation. Currently, there are no specifications available that describe exactly where within the runtime the handlers are invoked, and what happens if the handlers fail. For more information on adding JAX-RPC handlers, see “JAX-RPC and SOAP Handlers” in Specifying SOAP Handlers for a Web Service.

It is recommended that you only use handlers for operations that don't modify the message, such as inspection and logging activities.

@jws:location Specifies the URL at which a Web service control accepts requests for each supported protocol.


http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/tags/navJwsAnnotations.html


http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/conversation-lifetime.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/howdoI/managecon.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/handler.html

http://edocs/workshop/docs81/doc/en/workshop/guide/getstarted/conSOAPHandlers.html

http://edocs/workshop/docs81/doc/en/workshop/guide/getstarted/conSOAPHandlers.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/location.html

Web Se rv ice Features in Busi ness P rocesses

@jws:parameter-xml Specifies characteristics for marshaling data between XML messages and the data in a Java declaration's parameters.

JPDs can specify XML Query maps that are invoked before receiving requests and before sending callbacks, via the @jws:parameter-xml annotation inherited from WebLogic Workshop. For more information, see Transforming XML Messages with XQuery Maps.

When working with this annotation, you should consider the following @jws:parameter-xml annotation attribute information:

schema-element, xquery, xquery-ref, xml-map

It is recommended that you do not use the above attributes.

include-java-types

In general, this feature works for all operations, except for include-java-types.

@jws:protocol Specifies the protocols and message formats a Web service can accept or a Web Service control will send to the service it represents.

When working with this annotation, you should consider the following @jws:protocol annotation attribute information:

form-post and form-get

When you generate a Service Broker control and build or deploy the process that includes the generated Service Broker control, and then send a document to the process using HTTP post, the WSDL generated for the HTTP-post protocol from the process definition (JPD) will be missing response message information.

It is recommended that you do not use this feature.

http-soap12

Currently, there is no specification available to describe how http-soap12 binding is implemented for JPDs. If you use this feature, you do so at your own risk.

jms-soap

Currently, there is no specification available that describes the JPD to WSDL mapping for http-soap. If you use this feature, you do so at your own risk.

java-call

The java-call attribute has been deprecated and is ignored.


http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/parameter-xml.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/guide/xquerymap/navXQuery.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/protocol.html


JwsContext InterfaceThis section provides information about the some of the methods associated with the com.bea.control.JwsContext Interface. The JwsContext Interface provides access to container services that support Web services (JWS files). For more information, see “JwsContext Interface” in com.bea.control Package.

General PropertiesGeneral Properties are displayed in the Property Editor for all the nodes in a business process.

For a given node, the following properties are displayed:

nameThis is the name of the node selected in WebLogic Workshop. You can change the name of the associated node by clicking on this property and entering a new name. Note that the

@jws:reliable Specifies that a Web service should use reliable messaging, and specifies how long messages must be retained by the server in order to perform detection and removal of duplicates. Once you have specified that the Web service should use reliable messaging, you can then enable or disable it for a given method.

When you generate a Service Broker control with a @jws:reliable annotation, the generated WSDL <operation> tags have no SOAP header declarations. However, in reality, the SOAP messages that will be generated by this control will have SOAP headers. This annotation is not supported in this release.

@jws:wsdl Specifies a WSDL file that is implemented by a Web service.

To learn about all the @jws annotations, see Web Service Annotations.

Note: WS-Security policy (WSSE) files are not supported for business processes (JPDs). Therefore, the following annotations are not supported for JPD files: @jws:ws-security-callback and @jws:ws-security-service. To learn more about WSSE in Web services, see WS-Security Policy File Reference.

setUnderstoodInputHeaders() method This method is not supported for asynchronous operations.

setCalbackLocation() method This method is not supported for Process Control callbacks.


http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/reliable.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/wsdl.html


http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/ws-security-callback.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/jws/ws-security-service.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/configfiles/con_wsse_policyFile.html

http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/configfiles/con_wsse_policyFile.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/java-class/com/bea/control/package-summary.html

Message Buf fe r

name is changed in the Design View in keeping with the change you make in the Property Editor.

Note that for the scenario in which the Start node of a business process is selected in the Design View, the name of the business process (JPD file) is displayed.

notesEnter any notes that you want associated with your business process by clicking on this property to open the Property Text Editor. Notes entered in the editor will also be displayed in the WebLogic Integration Administration Console at run time.

Related TopicsGuide to Building Business Processes

Message BufferThis topic is discussed fully in the following locations:

@common:message-buffer Annotation

Buffering Client Messages

Method PropertiesFor a given node, the following properties are displayed:

method nameThe name of the method that is exposed via the Web Services Description Language (WSDL) when you make your business process available as a Web service. For a Client Request node, it is the name of Java method that will be called when that node is executed.

handler method nameFor a Client Response node, it is the name of the Java method that will be called when that node is executed.

sync/async callback nameAvailable only in the Client Request node, it is the name of the callback method. You can find this name in the method name property in the associated Client Response node.

Related TopicsSynchronous Clients for Asynchronous Business Processes


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideIntro.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideSync.html

http://e-docs.bea.com/workshop/docs81/doc/en/workshop/javadoc-tag/common/message-buffer.html

http://e-docs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguidebufferingclientmessages.html


Variable PropertiesWhen you click on any business process variable in the Data Palette, its Variable Properties are displayed in the Property Editor.

For a given variable, the following properties are displayed:

nameDisplays the name of the variable. You can double click the name and change it in the Property Editor.

typeDisplays the data type for the variable. This is a read-only field.

value

Displays the initial value for the variable if one has been assigned. Click ... in the value field to access the Source View for the variable in question—you can edit the initial value assigned to a given variable in the Source View.

Related TopicsBusiness Process Variables and Data Types

Creating Variables

Control PropertiesWhen you click any control node of a business process (Control Send, Control Receive, Control Send with Return) in the Design View, its Properties are displayed in the Property Editor in a control group. The properties in the Property Editor are read-only.

The properties that are displayed in the Property Editor depend on which type of control you select in the Design View:

Control Send

Control Receive

Control Send with Return


http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideDataTypes.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/wfguide/wfguideDataTypesCreate.html

Cont ro l P rope r t ies

Control Sendtarget control

The control to which this node is sending a message.

target methodThe method being invoked on the target control.

Control Receivesource control

The control from which this node is receiving a message.

callback methodThe callback method on the source control.

Control Send with Returntarget control

The control to which this node is sending a message.

target methodThe method being invoked on the target control.

Related Topics@common:control Annotations

Using Integration Controls

@common:context Annotations


http://edocs.bea.com/workshop/docs81/doc/en/integration/javadoc-tag/common/control.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/controls/controlsIntro.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/javadoc-tag/common/context.html

C H A P T E R 18

Data Transformation Annotations

This section provides reference information for WebLogic Integration data transformation annotations (@dtf:name_of_annotation).

Topics Included in This Section@dtf:xquery Annotation

Specifies global XQuery functions that can be used by the queries specified in a DTF file and XQuery namespaces that can be used within the scope of the prologue of the DTF file.

@dtf:transform AnnotationSpecifies the XQuery and XSLT abstract methods in a DTF file. During run time, a business process (JPD) invokes the abstract method which in turn invokes the associated XSLT or query (written in the XQuery language.)

@dtf:schema-validate AnnotationSpecifies if the source parameters and/or the return value should be schema validated. The schema-validate annotation is an optional annotation associated with @dtf:transform methods.

@dtf:xquery-function AnnotationSpecifies that a user-defined Java method (non-abstract) method in a DTF file can be invoked from queries (written in the XQuery language).

General PropertiesDescribes a set of general properties that are displayed in the Property Editor for the methods in a DTF file.

Data Transformation Annotations Reference 18-1

Data Trans fo rmat ion Annota t i ons

@dtf:xquery AnnotationThe @dtf:xquery annotation with the prologue attribute defines global XQuery functions that can be used by the queries specified in a DTF file. (The call to the function is made in the XQ file that contains the query.) In addition, the @dtf:xquery annotation with the prologue attribute specifies XQuery namespaces that can be used within the scope of the prologue of the DTF file.

Note: The @dtf:xquery annotation is optional.

SyntaxThe syntax of the @dtf:xquery annotation is dependant on the number of lines in the annotation as described in the following options:

For XQuery namespace and function definitions on multiple lines, the following syntax is used:

@dtf:xquery prologue :: xquery_namespaces_and_function_definitions ::

Where xquery_namespaces_and_function_definitions defines the XQuery namespace and function definitions specified on multiple lines in the annotation.

For XQuery namespaces and function definitions on a single line, the following syntax can be used:

@dtf:xquery prologue=”xquery_namespace_and_function_definition”

Where xquery_namespace_and_function_definition defines the XQuery namespace and function definitions specified on a single line in the annotation.

Note: The only attribute supported for the @dtf:xquery annotation is the prologue attribute.

RemarksThe following example @dtf:xquery annotation defines a namespace and a function on multiple lines:

/**

* @dtf:xquery prologue::

* declare namespace env = "http://www.example.org/envelope"

*

* define function wrapInEnvelope(element $e) returns element

* {

18-2 Data Transformation Annotations Reference

@dtf : xquer y Annota t i on

* <env:envelope>

* {$e}

* </env:envelope>

* }

* ::

*/

Caution: The namespaces definitions must be listed before the function definitions in the annotation.

Note: The namespace(s) defined in the prologue can only be used in the scope of the prologue (as shown in the preceding example) and cannot be referred to from the query (stored in the XQ file) while function definitions can be used in queries (stored in the XQ file).

You can add the @dtf:prologue annotation using one of the following procedures:

Using the Property Editor:

a. Open the DTF file in the Design View.

b. Select the DTF name in the Design View.

c. Click prologue in the Property Editor.

d. Click . . . next to the prologue field.

The Property Test Editor is displayed.

e. In the Property Test Editor, enter the desired namespaces and function definitions and click OK.

Open the DTF file in the Source View and enter the @dtf:prologue annotation after the last import statements but before the class definition statement for the DTF as shown highlighted in bold in the following example code listing:

package examples;import com.bea.xml.XmlObject;import com.bea.xml.XmlObjectList;/** * @dtf:xquery prologue:: * define function debugFunction(xs:string $str) returns xs:string {* concat("DTF XQuery: ", $str) * } * :: */ public abstract class examplesimplements com.bea.transform.TransformSource



{static final long serialVersionUID = 1L;/*** @dtf:transform xquery-ref="myTransMethod.xq"* @dtf:schema-validate return-value="false" parameters="false"

*/public abstract stockquotes.PriceQuoteDocument

myTransMethod(stockquotes.PriceQuoteDocument PriceQuoteDoc);/** * @dtf:transform xquery-ref="mySecondTransMethod.xq" * @dtf:schema-validate return-value="false" parameters="false" */ public abstract org.example.quote.QuoteDocument

mySecondTransMethod(noNamespace.SupplierDocument SupplierDoc);}

The @dtf:xquery annotation is a class level annotation. A function defined in the DTF class can be used by all the queries defined in the DTF file. In the preceding example, the debugFunction function can be used in both the myTransMethod query (stored in the myTransMethod.xq file) and the mySecondTransMethod query (stored in the mySecondTransMethod.xq file).

Related TopicsTo learn more see XQuery Prologs.

To learn about the XQuery language, see the XQuery 1.0: An XML Query Language Specification - W3C Working Draft 16 August 2002 available from the W3C web site at the following URL:

http://www.w3.org/TR/2002/WD-xquery-20020816/

To learn data transformations, see the following topics:

Guide to Data Transformations


@dtf:transform AnnotationThe @dtf:transform annotation annotates the XQuery and XSLT abstract methods in a DTF file. During run time, a business process (JPD) invokes the abstract method which in turn invokes the associated XSLT or query (written in the XQuery language.)

SyntaxThe @dtf:transform annotation can specify one and only one of the following attributes:


http://edocs.bea.com/workshop/docs81/doc/en/workshop/reference/refXQuery/refXQueryLangPrologs.html



http://e-docs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguideIntro.html


@dtf : t ransform Annota t i on

xquery-ref Attribute

xquery Attribute

xslt-ref Attribute

xslt Attribute

xquery-ref Attribute@dtf:transform

xquery-ref="myTrans.xq"

Where myTrans specifies the XQ file that contains the query written in the XQuery language. During run time, if the abstract method is invoked by a business process, the associated query stored in the XQ file is invoked by the XQuery engine.

The following example code segment shows a @dtf:transform annotation specifying the xquery-ref attribute:

/**

* @dtf:transform xquery-ref="myXQueryMethod.xq"

* @dtf:schema-validate return-value="false" parameters="false"

*/

public abstract noNamespace.SupplierDocument

myXQueryMethod(noNamespace.PurchaseOrderDocument PurchaseOrderDoc);

During run time, if the myXQueryMethod abstract method is invoked by a business process, the query stored in the myXQueryMethod.xq is invoked by the XQuery engine.

A dtf:transform annotation with the xquery-ref attribute is generated when you create a transformation method in a DTF file and configure the transformation method to be a XQuery method. To learn more, see Creating a Transformation File and a Transformation Method in the Guide to Data Transformation.

xquery Attribute@dtf:transform xquery ::

xquery_code::

Where xquery_code specifies the inline query (written in the XQuery language) to be invoked by the business process during run time.


http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguidemappercreatecontrolmethod.html


The following example code segment shows a @dtf:transform annotation specifying the xquery attribute:

/**

* @dtf:transform xquery ::

* <Supplier>

* <id>{ data($PurchaseOrderDoc/partId) }</id>

* </Supplier>

* ::

*/


myXQueryInlineMethod(noNamespace.PurchaseOrderDocument PurchaseOrderDoc);

The unbound source variables used in the XQuery code must correspond in name and type to the Java transformation (abstract) method parameters defined in the DTF file. (An unbound source variable is a variable used in the XQuery code that is not first defined by an XQuery let statement.) As shown highlighted in bold in the preceding example code listing, the source $PurchaseOrderDoc variable used in the inline XQuery code is defined as the parameter in the myXQueryInlineMethod transformation method as type: PurchaseOrderDocument.

You can add the @dtf:transform annotation with the xquery attribute using one of the following procedures:

Open the DTF file in the Source View and enter the @dtf:transform annotation with the xquery attribute as shown in the presiding example code listing.

Using the Property Editor:

a. Open the DTF file in the Design View.

b. In the Design View, select a Transformation (abstract) method.

c. In the Property Editor, under transform, click the xquery attribute.

The field to the right of the xquery attribute becomes active.

d. Paste the query into the xquery field.

xslt-ref Attribute@dtf:transform

xslt-ref="myXSL.xsl"


@dtf : t ransform Annota t i on

Where myXSL specifies the XSL file that contains the eXtensible Stylesheet Language code. XSLT is an older language defined by the W3C that supports the use of style sheets for the conversion of XML data.

The following example code segment shows a @dtf:transform annotation specifying the xslt-ref attribute:

/**

* @dtf:transform xslt-ref="../myXSLT.xsl"

*/

public abstract com.bea.xml.XmlObject myXsltMethod(com.bea.xml.XmlObject

source);

During run time, if the myXsltMethod abstract method is invoked by a business process, the associated XSLT stored in the myXSLT.xsl is invoked by the XSLT processor.

The return type and the first parameter of the method must be XmlObject or a typed XMLBeans class. The remaining parameters are treated as XSLT parameters.

A dtf:transform annotation with the xslt-ref attribute is generated when you create a transformation method in a DTF file and configure the transformation method to be a XSLT method. To learn more, see Transforming Data Using XSLTs in the Guide to Data Transformation.

xslt Attribute@dtf:transform xslt ::

XSL_Code::

Where XSL_code specifies the inline XSL code to be invoked by the business process during run time.

The return type and the first parameter of the method must be XmlObject or a typed XMLBeans class. The remaining parameters are treated as XSLT parameters.

You can add the @dtf:transform annotation with the xslt attribute using one of the following procedures:

1. Open the DTF file in the Source View and enter the @dtf:transform annotation with the xslt attribute above the Java code defining the XSLT transformation method.

2. In the Property Editor, open the DTF file in the Design View.

3. In the Design View, select a Transformation (abstract) method.


http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguideXSLT.html


4. In the Property Editor, under transform, click the xslt attribute.

5. The field to the right of the xslt attribute becomes active.

6. Paste the XSL code into the xslt field.



@dtf:schema-validate AnnotationSpecifies if the source parameters and/or the return value should be schema validated. The schema-validate annotation is an optional annotation associated with @dtf:transform methods.

Syntax@dtf:schema-validate

return-value="true" | "false"parameters="true" | "false"

Attributesreturn-value

If this parameter is set to true, during run time, if the return type has an associated schema, it will be validated against its schema type after the transformation is executed. A typed XML return value will be schema validated against its XML Schema and a typed non-XML return value will be validated against the schema in the MFL file. A return types which is untyped or is a Java primitive will not be validated because it does not have an associated schema.

parametersIf this parameter is set to true, during run time, the source parameters that have an associated schema will be validated against their schema types before the transformation is executed. All typed XML parameters will be schema validated against their XML Schema and typed non-XML parameters will be validated against the schema in the MFL file. Source parameters which are untyped or are Java primitives will not be validated because they do not have an associated schema.


http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguideIntro.html


@dtf : xquer y- func t i on Anno ta t i on

RemarksIn the following example, the @dtf:schema-validate annotation defines that during run time, when the transformation method myXQueryMethod is executed, the return value will be schema validated but the source parameters of the transformation method will not, as shown highlighted in bold in the following code segment:

/**

* @dtf:transform xquery-ref="myXQueryMethod.xq"

* @dtf:schema-validate return-value="true" parameters="false"

*/


myXQueryMethod(noNamespace.PurchaseOrderDocument PurchaseOrderDoc);

Related TopicsSee “Schema Validating During Run Time” in Validating in the Guide to Data Transformation.

@dtf:transform Annotation

@dtf:xquery-function AnnotationSpecifies that a user-defined Java method (non-abstract) method in a DTF file can be invoked from queries (written in the XQuery language).

Syntax@dtf:xquery-function

RemarksIn the following example, the @dtf:xquery-function annotation defines that the Java method calculateTotalPrice that can be invoked from a query during run time:

/**

* @dtf:xquery-function

*/

public float calculateTotalPrice(float taxRate, int quantity, float price,

boolean fillOrder)

{

float totalTax, costNoTax, totalCost;


http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguidemappervalidating.html


if (fillOrder)

{

// Calculate the total tax

totalTax = taxRate * quantity * price;

// Calculate the total cost without tax

costNoTax = quantity * price;

// Add the tax and the cost to get the total cost

totalCost = totalTax + costNoTax;

}

else

{

totalCost = 0;

}

return totalCost;

}

Related TopicsSee “Invoking Functions or Operators in a Query” in Modifying Links Using the Target Expression Tab in the Guide to Data Transformation.

See “Create a User-Defined Java Method to Invoke From the Join Query” in Step 4: Mapping Repeating Elements—Creating a Join in the Tutorial: Building Your First Data Transformation.

General PropertiesGeneral Properties are displayed in the Property Editor for all the methods in a DTF file.

For a given method, the name property is displayed. The name property defines the name of the selected DTF method. You can change the name of the associated method by clicking on this property and entering a new name. Note that the name is changed in the Design View in keeping with the change you make in the Property Editor.


@dtf:transform Annotation


http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguidemapperexpressbuilder.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguidemapperexpressbuilder.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/dttutorial/tutWLIDataTransStep4.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/dttutorial/tutWLIDataTransStep4.html

http://edocs.bea.com/workshop/docs81/doc/en/integration/dtguide/dtguideIntro.html

bea weblogic integration · beaweblogic integration ™ annotations reference version 8.1 service...

Documents