bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Programming BPM Client Apps

DTD Formats

This appendix describes the WebLogic Integration DTD formats, including the following:

- Audit DTD

- Business Calendar DTD

- Client Call Addin Request DTD

- Client Call Addin Response DTD

- Client Call Program Request DTD

- Client Call Program Response DTD

- Client Message Box Request DTD

- Client Message Box Response DTD

- Client Request DTD

- Client Set Variables Request DTD

- Client Set Variables Response DTD

- Import Response DTD

- Statistics Request DTD

- Statistics Response DTD

- Template DTD

- Template Definition DTD

- Workload Request DTD

- Workload Response DTD

Audit DTD

The Audit DTD describes the format of the XML document that is used by the auditing facility when generating auditing statistics.

The following sections describe the Audit DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Audit DTD Example

Hierarchy Diagram

The following diagram illustrates the Audit DTD hierarchy.

Figure A-1 Audit DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Audit DTD, Audit.dtd.

>     <!ELEMENT wlpiresponse (instanceid, templatedefinitionid, wlpirequest)>
>     <!ELEMENT wlpirequest (started, requestor, templateid, template-name,
>                            templatedefinitionid, instanceid, actions, completed)>
>     <!ELEMENT actions ((error | setvariable | activatetask | dotask | marktaskdone |
>                         unmarktaskdone | unassigntask | settaskcomment |
>                         settaskpriority | settaskproperties | settaskduedate |
>                         rerouted | assigntask | instantiated | auditentry |
>                         evaluatecondition | workflowaborted | setworkflowcomment)*)>
>     <!ELEMENT completed (#PCDATA)>
>     <!ELEMENT instanceid (#PCDATA)>
>     <!ELEMENT requestor (#PCDATA)>
>     <!ELEMENT started (#PCDATA)>
>     <!ELEMENT templatedefinitionid (#PCDATA)>
>     <!ELEMENT templateid (#PCDATA)>
>     <!ELEMENT template-name (#PCDATA)>
>     <!ELEMENT error (#PCDATA)>
>     <!ATTLIST error time CDATA #REQUIRED id CDATA #REQUIRED>
>     <!ELEMENT setvariable (#PCDATA)>
>     <!ATTLIST setvariable time CDATA #REQUIRED variable NMTOKEN #REQUIRED)>
>     <!ELEMENT activatetask (#PCDATA)>
>     <!ATTLIST activatetask time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT dotask (#PCDATA)>
>     <!ATTLIST dotask time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT marktaskdone (#PCDATA)>
>     <!ATTLIST marktaskdone time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT unmarktaskdone (#PCDATA)>
>     <!ATTLIST unmarktaskdone time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT unassigntask (#PCDATA)>
>     <!ATTLIST unassigntask time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT settaskcomment (#PCDATA)>
>     <!ATTLIST settaskcomment time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT settaskpriority (#PCDATA)>
>     <!ATTLIST settaskpriority time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT settaskproperties (#PCDATA)>
>     <!ATTLIST settaskproperties time CDATA #REQUIRED taskid CDATA #REQUIRED
>       name CDATA>
>     <!ELEMENT settaskduedate (#PCDATA)>
>     <!ATTLIST settaskduedate time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT rerouted (#PCDATA)>
>     <!ATTLIST rerouted time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT assigntask (#PCDATA)>
>     <!ATTLIST assigntask time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT instantiated (#PCDATA)>
>     <!ATTLIST instantiated time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT auditentry ANY>
>     <!ATTLIST auditentry time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT evaluatecondition (#PCDATA)>
>     <!ATTLIST evaluatecondition time CDATA #REQUIRED taskid CDATA #REQUIRED
>       name CDATA>
>     <!ELEMENT workflowaborted (#PCDATA)>
>     <!ATTLIST workflowaborted time CDATA #REQUIRED taskid CDATA #REQUIRED name CDATA>
>     <!ELEMENT setworkflowcomment (#PCDATA)>
>     <!ATTLIST setworkflowcomment time CDATA #REQUIRED taskid CDATA #REQUIRED
>       name CDATA>

Element Descriptions

The following table describes the elements of the Audit DTD.

Table A-1 Audit DTD Element

Element

Description

Example Value

actions

Defines the actions that were performed.

Defines zero or more occurrences of the following subelements:

- error

- setvariable

- activatetask

- dotask

- marktaskdone

- unmarktaskdone

- unassigntask

- settaskcomment

- settaskpriority

- settaskproperties

- settaskduedate

- rerouted

- assigntask

- instantiated

- auditentry

- evaluatecondition

- workflowaborted

- setworkflowcomment

See Audit DTD Example.

activatetask

Defines the following attributes:

- time: Time at which the task was activated.

- taskid: ID of the task that has been activated.

- name: Name of the task that has been activated.

<activatetask
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

assigntask

Defines the following attributes:

- time: Time at which the task was assigned.

- taskid: ID of the task that has been assigned.

- name: Name of the task that has been assigned.

<assigntask
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

auditentry

Defines the following attributes:

- time: Time at which the audit entry was logged.

- taskid: ID of the task for which an audit entry has been logged.

- name: Name of the task that for which an audit entry has been logged.

<auditentry
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

completed

Time at which the task execution completed.

<completed>2001-06-12
12:45:45.115
</completed>

dotask

Defines the following attributes:

- time: Time at which the task was executed.

- taskid: ID of the task that has been executed.

- name: Name of the task that has been executed.

<dotask
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

error

Defines the following attributes:

- time: Time at which the error occurred.

- id: Error ID.

<error
time="2001-06-12
12:45:44.824"
id="2"/>

evaluatecondition

Defines the following attributes:

- time: Time at which a condition was evaluated.

- taskid: ID of the task for which a condition has been evaluated.

- name: Name of the task for which the condition has been evaluated.

<evaluatecondition
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

instanceid

ID of the workflow instance that is the target of the response document.

<instanceid>
2
</instanceid>

instantiated

Defines the following attributes:

- time: Time at which the task was instantiated.

- name: ID of the task that has been instantiated.

<instantiated
time="2001-06-12
12:45:44.824"
name="Start Test"/>

marktaskdone

Defines the following attributes:

- time: Time at which the task was marked complete.

- taskid: ID of the task that has been marked as complete.

- name: Name of the task that has been marked as complete.

<marktaskdone
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

requestor

ID requestor.

<requestor>
wlisystem
</requestor>

rerouted

Defines the following attributes:

- time: Time at which the task was rerouted.

- taskid: ID of the task that has been rerouted.

- name: Name of the task that has been rerouted.

<rerouted
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

settaskcomment

Defines the following attributes:

- time: Time at which the task comment was set.

- taskid: ID of the task for which a comment has been set.

- name: Name of the task for which a comment has been set.

<settaskcomment
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1">
This is a comment.
</settaskcomment>

settaskduedate

Defines the following attributes:

- time: Time at which the task due date was set.

- taskid: ID of the task for which a task due date has been set.

- name: Name of the task for which a task due date has been set.

<settaskduedate
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1">
</settaskduedate>

settaskpriority

Defines the following attributes:

- time: Time at which the task priority was set.

- taskid: ID of the task for which a priority has been set.

- name: Name of the task for which a priority has been set.

<settaskpriority
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1">
</settaskpriority>

settaskproperties

Defines the following attributes:

- time: Time at which the task properties were set.

- taskid: ID of the task for which properties have been set.

- name: Name of the task for which properties have been set.

<settaskproperties
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1">
</settaskproperties>

setvariable

Defines the following attributes:

- time: Time at which the variable was set.

- variable: Name of the variable in XML name token (NMTOKEN) format.

<setvariable
time="2001-06-12
12:45:44.824"
variable="test1">
value1
</setvariable>

setworkflowcomment

Defines the following attributes:

- time: Time at which the workflow comment was set.

- taskid: ID of the task for which a comment has been set.

- name: Name of the task for which a comment has been set.

<setworkflowcomment
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1">
</setworkflowcomment>

started

Time at which the task execution started.

<started>
2001-06-12
12:45:44.824
</started

templatedefinitionid

ID of the workflow template definition that is the target of the response document.

<templatedefinitionid>
2
</templatedefinitionid>

templateid

ID of the workflow template that is the target of the response document.

<templateid>
2
</templateid>

template-name

Name of the workflow template.

<template-name>
Start Test
</template-name>

unassigntask

Defines the following attributes:

- time: Time at which the task was unassigned.

- taskid: ID of the task for which assignment has been revoked.

- name: Name of the task for which assignment has been revoked.

<unassigntask
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

unmarktaskdone

Defines the following attributes:

- time: Time at which the task was marked as incomplete.

- taskid: ID of the task that has been marked as incomplete.

- name: Name of the task that has been marked as incomplete.

<unmarktaskdone
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

wlpirequest

Defines the request, including the following subelements:

- started

- requestor

- templateid

- templatedefinitionid

- instanceid

- actions

- completed

See Audit DTD Example.

wlpiresponse

Root element.

Defines the following subelements:

- instanceid

- templatedefinitionid

- wlpirequest

See Audit DTD Example.

workflowaborted

Defines the following attributes:

- time: Time at which the workflow was aborted.

- taskid: ID of the task that caused the workflow to be aborted.

- name: Name of the task that has been marked as incomplete.

<workflowaborted
time="2001-06-12
12:45:44.824"
taskid="2"
name="Task 1"/>

Audit DTD Example

The following example illustrates a valid application of the Audit DTD:

>     <wlpirequest>
>        <started>2001-06-12 12:45:44.824</started
>        <requestor>wlisystem</requestor>
>        <templateid>2</templateid>
>        <template-name>Start Test</template-name>
>        <templatedefinitionid>2</templatedefinitionid>
>        <instanceid>8010</instanceid>
>        <actions>
>           <instantiated time="2001-06-12 12:45:44.824"
>              name="Start Test"/>
>           <setvariable time="2001-06-12 12:45:44.824"
>              variable="test1">value1</setvariable>
>           <setvariable time="2001-06-12 12:45:44.824"
>              variable="test2">value2</setvariable>
>           <activatetask time="2001-06-12 12:45:44.824" taskid="2"
>              name="Task 1"/>
>           <dotask time="2001-06-12 12:45:44.824" taskid="2"
>              name="Task 1"/>
>           <marktaskdone time="2001-06-12 12:45:44.824"
>              taskid="2" name="Task 1"/>
>           <workflowdone time="2001-06-12 12:45:45.115"
>              name="Start Test"/>
>        </actions>
>        <completed>2001-06-12 12:45:45.115</completed>
>     </wlpirequest>

Business Calendar DTD

The Business Calendar DTD describes the format of the XML document that is used to create business calendars. Business calendars are used to define the operating hours for an organization. For more information about configuring business calendars, see Configuring Business Calendars.

The following sections describe the Business Calendar DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Business Calendar DTD Example

Hierarchy Diagram

The following diagram illustrates the Business Calendar DTD hierarchy.

Figure A-2 Business Calendar DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Business Calendar DTD, BusinessCalendar.dtd:

>     <!ELEMENT calendar (id, name, timezone, interval*)>
>     <!ELEMENT date (#PCDATA)>
>     <!ELEMENT dateinterval (fromdate, todate)>
>     <!ELEMENT days (#PCDATA)>
>     <!ELEMENT exclude (months*, days*, date*, timeinterval*, dateinterval*)>
>     <!ELEMENT fromdate (#PCDATA)>
>     <!ELEMENT fromtime (#PCDATA)>
>     <!ELEMENT id (#PCDATA)>
>     <!ELEMENT include (months*, days*, date*, timeinterval*, dateinterval*)>
>     <!ELEMENT interval (fromdate, todate, exclude*, include*)>
>     <!ELEMENT months (#PCDATA)>
>     <!ELEMENT name (#PCDATA)>
>     <!ELEMENT timeinterval (fromtime, totime)>
>     <!ELEMENT timezone (#PCDATA)>
>     <!ELEMENT todate (#PCDATA)>
>     <!ELEMENT totime (#PCDATA)>

Element Descriptions

The following table describes the elements of the Business Calendar DTD.

Table A-2 Business Calendar DTD Elements

Element | Description | Example Value
--- | --- | ---
calendar | Root element. You must define the following subelements: id name timezone interval (zero or more) | See Business Calendar DTD Example.
date | Date to be included or excluded. This date must be specified using the following format: month dd, yyyy where month specifies the name of the month (such as January), dd specifies the day, and yyyy specifies the year. | <date> December 25, 2001 </date>
dateinterval | Interval of time to be included in or excluded from the calendar. You must define the following subelements: fromdate todate | <dateinterval> <fromdate> January 1, 2001 </fromdate> <todate> January 1, 2002 </todate> </dateinterval>
days | Day to be included or excluded. The value of this element is a text string specifying the name of the day (such as Sunday). | <days>Saturday</days>
exclude | Rule that defines an interval of time to be excluded from the main interval. You can define the following subelements: months (zero or more) days (zero or more) date (zero or more) timeinterval (zero or more) dateinterval (zero or more) | <exclude> <days> Saturday, Sunday </days> <date> January 1, 2001 </date> </exclude>
fromdate | Subelement of interval or dateinterval. When used as subelement of interval, specifies the start date for an interval. When used as subelement of dateinterval, it is specific to the include or exclude. This date must be specified using the following format: month dd, yyyy where month specifies the name of the month (such as January), dd specifies the day, and yyyy specifies the year. | <fromdate> January 1, 2001 </fromdate>
fromtime | Start time from which the business calendar is in effect, or a subelement of timeinterval, in which case it specifies a range of time to include or exclude. This time must be specified using the following format: hh:mm, where hh specifies the hour and mm specifies the minutes. | 08:00
id | Unique ID. | <id>10234</id>
include | Rule that defines an interval of time to be included in the main interval. You can define the following subelements: months (zero or more) days (zero or more) date (zero or more) timeinterval (zero or more) dateinterval (zero or more) | <include> <timeinterval> 08:00, 17:00 </timeinterval> </include>
interval | Interval of time that the calendar is in effect. You must define the following subelements: fromdate todate exclude (zero or more) include (zero or more) | <interval> <fromdate> 20010101 </fromdate> <todate> 20020101 </todate> <exclude> <date> 20011225 </date> <days> Saturday, Sunday </days> </exclude> <include> <timeinterval> 08:00. 17:00 </timeinterval> </include> </interval>
months | Month to be included or excluded. The value of this element is a text string specifying the name of the month (such as January). | <months> August </months>
name | Calendar name. | <name> MyCalendar </name>
timeinterval | Interval of time to be included in or excluded from the calendar. You must define the following subelements: fromtime totime | <timeinterval> <fromtime> 17:00:00 </fromtime> <totime> 08:00:00 </totime> </timeinterval>
timezone | Calendar time zone. (See Note following table for valid values.) | <timezone> EST </timezone>
todate | Date until which the business calendar remains in effect. This date must be specified using the following format: month dd, yyyy where month specifies the name of the month (such as January), dd specifies the day, and yyyy specifies the year. | <todate> January 1, 2002 </todate>
totime | Time until which the business calendar is in effect. This time must be specified using the following format: hh:mm, where hh specifies the hour and mm specifies the minutes. | <totime>17:00</totime>

Note: Valid timezone values include: Africa/Lome, GMT, UTC, Atlantic/Faeroe, Atlantic/Canary, Europe/Dublin, Europe/Lisbon, Europe/London, Africa/Luanda, Africa/Porto-Novo, Africa/Bangui, Africa/Kinshasa, Africa/Douala, Africa/Libreville, Africa/Malabo, Africa/Niamey, Africa/Lagos, Africa/Ndjamena, Africa/Tunis, Africa/Algiers, Europe/Andorra, Europe/Tirane, Europe/Vienna, Europe/Brussels, Europe/Zurich, Europe/Prague, Europe/Berlin, Europe/Copenhagen, Europe/Madrid, Europe/Gibraltar, Europe/Budapest, Europe/Rome, Europe/Vaduz, Europe/Luxembourg, Africa/Tripoli, Europe/Monaco, Europe/Malta, Africa/Windhoek, Europe/Amsterdam, Europe/Oslo, Europe/Warsaw, Europe/Stockholm, Europe/Belgrade, Europe/Paris, ECT, Africa/Bujumbura, Africa/Gaborone, Africa/Lubumbashi, Africa/Maseru, Africa/Blantyre, Africa/Maputo, Africa/Kigali, Africa/Khartoum, Africa/Mbabane, Africa/Lusaka, Africa/Harare, CAT, Africa/Johannesburg, Europe/Sofia, Europe/Minsk, Asia/Nicosia, Europe/Tallinn, Africa/Cairo, ART, Europe/Helsinki, Europe/Athens, Asia/Jerusalem, Asia/Amman, Asia/Beirut, Europe/Vilnius, Europe/Riga, Europe/Chisinau, Europe/Bucharest, Europe/Kaliningrad, Asia/Damascus, Europe/Kiev, Europe/Istanbul, EET, Asia/Bahrain, Africa/Djibouti, Africa/Asmera, Africa/Addis_Ababa, EAT, Africa/Nairobi, Indian/Comoro, Asia/Kuwait, Indian/Antananarivo, Asia/Qatar, Africa/Mogadishu, Africa/Dar_es_Salaam, Africa/Kampala, Asia/Aden, Indian/Mayotte, Asia/Riyadh, Asia/Baghdad, Europe/Simferopol, Europe/Moscow, Asia/Tehran, MET, Asia/Dubai, Indian/Mauritius, Asia/Muscat, Indian/Reunion, Indian/Mahe, Asia/Yerevan, NET, Asia/Baku, Asia/Aqtau, Europe/Samara, Asia/Kabul, Indian/Kerguelen, Asia/Tbilisi, Indian/Chagos, Indian/Maldives, Asia/Dushanbe, Asia/Ashkhabad, Asia/Tashkent, Asia/Karachi, PLT, Asia/Bishkek, Asia/Aqtobe, Asia/Yekaterinburg, Asia/Calcutta, IST, Asia/Katmandu, Antarctica/Mawson, Asia/Thimbu, Asia/Colombo, Asia/Dacca, BST, Asia/Alma-Ata, Asia/Novosibirsk, Indian/Cocos, Asia/Rangoon, Indian/Christmas, Asia/Jakarta, Asia/Phnom_Penh, Asia/Vientiane, Asia/Saigon, VST, Asia/Bangkok, Asia/Krasnoyarsk, Antarctica/Casey, Australia/Perth, Asia/Brunei, Asia/Hong_Kong, Asia/Ujung_Pandang, Asia/Ishigaki, Asia/Macao, Asia/Kuala_Lumpur, Asia/Manila, Asia/Singapore, Asia/Taipei, Asia/Shanghai, CTT, Asia/Ulan_Bator, Asia/Irkutsk, Asia/Jayapura, Asia/Pyongyang, Asia/Seoul, Pacific/Palau, Asia/Tokyo, JST, Asia/Yakutsk, Australia/Darwin, ACT, Australia/Adelaide, Antarctica/DumontDUrville, Pacific/Truk, Pacific/Guam, Pacific/Saipan, Pacific/Port_Moresby, Australia/Brisbane, Asia/Vladivostok, Australia/Sydney, AET, Australia/Lord_Howe, Pacific/Ponape, Pacific/Efate, Pacific/Guadalcanal, SST, Pacific/Noumea, Asia/Magadan, Pacific/Norfolk, Pacific/Kosrae, Pacific/Tarawa, Pacific/Majuro, Pacific/Nauru, Pacific/Funafuti, Pacific/Wake, Pacific/Wallis, Pacific/Fiji, Antarctica/McMurdo, Asia/Kamchatka, Pacific/Auckland, NST, Pacific/Chatham, Pacific/Enderbury, Pacific/Tongatapu, Asia/Anadyr, Pacific/Kiritimati

Business Calendar DTD Example

The following example illustrates a valid application of the Business Calendar DTD:

>     <calendar>
>     	<id>acme2000</id>
>     	<name>Acme, Inc. Year 2000 Business Calendar</name>
>     	<timezone>EST</timezone>
>     	<interval>
>     		<fromdate>January 3, 2000</fromdate>
>     		<todate>December 31, 2000</todate>
>     		<exclude>
>     			<date>January 3, 2000</date>
>     			<date>December 25, 2000</date>
>     			<days>Saturday, Sunday</days>
>     			<dateinterval>
>     				<fromdate>
>     				   December 22, 2000 12:00:00
>     				</fromdate>
>     				<todate>
>     				   January 1, 2001 00:00:00
>     				</todate>
>     			</dateinterval>
>     			<timeinterval>
>     				<fromtime>17:00:00</fromtime>
>     				<totime>08:00:00</totime>
>     			</timeinterval>
>     		</exclude>
>     	</interval>
>     </calendar>

Client Call Addin Request DTD

The Client Call Addin Request DTD describes the format of the XML document that is used when calling an addin. The Client Call Addin Response DTD describes the format of the returned value. XML documents compliant with the Client Call Addin Request DTD can be passed when a template definition is being created, as part of the ActionSendXMLToClient action. For details, see Template Definition DTD.

The following sections describe the Client Call Addin Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Client Call Addin Request DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Call Addin Request DTD hierarchy.

Figure A-3 Client Call Addin Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Call Addin Request DTD, ClientCallAddInReq.dtd:

>     <!ELEMENT call-addin (actionid, parm*)>
>     <!ATTLIST call-addin name CDATA #REQUIRED
>                          mode (sync|async) "async">
>     <!ELEMENT actionid (#PCDATA)>
>     <!ELEMENT parm (#PCDATA)>

Element Descriptions

The following table describes the elements of the Client Call Addin Request DTD.

Table A-3 Client Call Addin Request DTD Elements

Element | Description | Example Value
--- | --- | ---
actionid | Action ID. | <actionid> 959395846210 </actionid>
call-addin | Root element. You must define the following subelements: actionid parm (zero or more) You must define the following attributes: name: Fully-qualified Java class name of the worklist addin to invoke, which must implement the com.bea.wlpi.client.worklist.WorklistAddIn interface. This attribute is required. mode: Program mode specifying whether or not the run-time client blocks while executing the client request. This value can be set to sync (synchronous mode), to block the run-time client until completion of the request, or async (asynchronous mode), to execute the client request as a background task. This attribute defaults to async. | See Client Call Addin Request DTD Example.
parm | Parameter. This value can be any character string. | <parm> itemNumber </parm>

Client Call Addin Request DTD Example

The following example illustrates a valid application of the Client Call Addin Request DTD:

>     <call-addin name="com.somedomain.someproduct.WorklistAddInImpl" mode="async">
>     	<actionid>959395846210</actionid>
>     	<parm>itemNumber</parm>
>     </call-addin>

Client Call Addin Response DTD

The Client Call Addin Response DTD describes the format of the XML document returned when an addin is called. (The Client Call Addin Request DTD describes the format of the XML document used to call the addin.)

You can use the XPath function to extract the returned value from the response file. For example:

>     XPath("/call-addin/child::text()")
>     XPath("/call-addin/text()")

If the return value contains objects such as XML nodes, the XPath expression must be constructed according to that structure.

The following sections describe the Client Call Addin Response DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Client Call Addin Response DTD hierarchy.

Figure A-4 Client Call Addin Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Call Addin Response DTD, ClientCallAddInResp.dtd.

>     <!ELEMENT call-addin ANY>

Element Descriptions

The following table describes the elements of the Client Call Addin Response DTD.

Table A-4 Client Call Addin Response DTD Elements

Element | Description
--- | ---
call-addin | Root element. The value of this element can consist of any combination of elements and text.

Client Call Program Request DTD

The Client Call Program Request DTD describes the format of the XML document that is used when an external program is called. (The Client Call Program Response DTD describes the format of the returned value.) XML documents compliant with the Client Call Program Request DTD can be passed when a template definition is being created, as part of the ActionSendXMLToClient action. For details, see Template Definition DTD.

The following sections describe the Client Call Program Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Client Call Program Response DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Call Program Request DTD hierarchy.

Figure A-5 Client Call Program Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Call Program Request DTD, ClientCallPgmReq.dtd.

>     <!ELEMENT call-program (actionid, parm*, env-var*)>
>     <!ATTLIST call-program name CDATA #REQUIRED
>                            mode (sync|async) "async">
>     <!ELEMENT actionid (#PCDATA)>
>     <!ELEMENT parm (#PCDATA)>
>     <!ELEMENT env-var (#PCDATA)>
>     <!ATTLIST env-var name NMTOKEN #REQUIRED>

Element Descriptions

The following table describes the elements of the Client Call Program Request DTD.

Table A-5 Client Call Program Request DTD Elements

Element | Description | Example Value
--- | --- | ---
call-program | Root element. You must define the following subelements: actionid parm (zero or more) env-var (zero or more) You must define the following attributes: mode: Program mode specifying whether or not the run-time client blocks while executing the client request. This value can be set to sync (synchronous mode), to block the run-time client until completion of the request, or async (asynchronous mode), to execute the client request as a background task. This attribute defaults to async. name: Program name. This attribute is required. | See Client Call Program Request DTD Example.
actionid | Action ID. | <actionid> 992456131534 </actionid>
parm | Parameter definition. This value can be any character string. | <parm> C:\WLPI\readme.txt </parm>
env-var | Environment variable definition. You must define a name attribute that specifies the name of the environment variable in XML name token (NMTOKEN) format. | <env-var name="TEMP"> C:\TEMP </env-var>

Client Call Program Request DTD Example

The following example illustrates a valid application of the Client Call Program Request DTD.

>     <call-program mode="async" name="notepad">
>       <actionid>992456131534</actionid>
>       <parm>C:\WLPI\readme.txt</parm>
>       <env-var name="TEMP">C:\TEMP</env-var>
>       <env-var name="TMP">C:\TEMP</env-var>
>     </call-program>

Client Call Program Response DTD

The Client Call Program Response DTD describes the format of the XML document returned when an external program is called. (The Client Call Program Request DTD describes the format of the XML document used to call the external program.)

You can use the XPath function to extract the returned value. For example:

>     XPath("/call-program/attribute::exit-value")
>     XPath("/call-program/@exit-value")

The following sections describe the Client Call Program Response DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Client Call Program Response DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Call Program Response DTD hierarchy.

Figure A-6 Client Call Program Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Call Program Response DTD, ClientCallProgramResp.dtd.

>     <!ELEMENT call-program EMPTY>
>     <!ATTLIST call-program exit-value NUMBER #REQUIRED>

Element Descriptions

The following table describes the elements of the Client Call Program Response DTD.

Table A-6 Client Call Program Response DTD Elements

Element | Description | Example Value
--- | --- | ---
call-program | Root element. This element is empty. You must define the exit-value attribute to specify a numeric exit code, as retrieved by the operating system, that is meaningful within the context of the calling workflow. Consult the appropriate program documentation for more information on valid exit codes. This attribute is required. | See Client Call Program Response DTD Example.

Client Call Program Response DTD Example

The following example illustrates a valid application of the Client Call Program Response DTD:

>     <call-program exit-value=0>
>     </call-program>

Client Message Box Request DTD

The Client Message Box Request DTD describes the format of the XML document that is used to prompt: (a) a user to respond to a message via a dialog box; and (b) retrieve the response. (The Client Message Box Response DTD describes the format of the returned value.) XML documents compliant with the Client Message Box Request DTD can be passed when a template definition is being created, as part of the ActionSendXMLToClient action. For details, see Template Definition DTD.

The following sections describe the Client Message Box Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Client Message Box Request DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Message Box Request DTD hierarchy.

Figure A-7 Client Message Box Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Message Box Request DTD, ClientMsgBoxReq.dtd.

>     <!ELEMENT message-box (#PCDATA, actionid)>
>     <!ATTLIST message-box title CDATA #IMPLIED
>                           style (plain|information|question|warning|
>                           error) "plain"
>                           options (ok|ok_cancel|yes_no|
>                           yes_no_cancel) "ok">
>     <!ELEMENT actionid (#PCDATA)>

Element Descriptions

The following table describes the elements of the Client Message Box Request DTD.

Table A-7 Client Message Box Request DTD Elements

Element | Description | Example Value
--- | --- | ---
actionid | Action ID. | <actionid> 990705990915 </actionid>
message-box | Root element. You must define the actionid subelement. You must define the following attributes: title: Text that appears in the title field of the message box. This attribute is optional. style: Message box style. The value of this element can be set to error, information, plain, question, or warning. It defaults to plain. options: Message box button options. Table A-8 defines the message box options that are valid based on the style value assigned. | See Client Message Box Request DTD Example.

The following table defines the message box options that are valid based on the style value assigned.

Table A-8 Valid Message Box Options Based on Style Value

Message Box Style | Message Box Options
--- | ---
error | ok, ok_cancel
information | ok
plain | ok, ok_cancel, yes_no, yes_no_cancel
question | yes_no, yes_no_cancel
warning | ok, ok_cancel

Client Message Box Request DTD Example

The following example illustrates a valid application of the Client Message Box Request DTD.

>     <message-box options="yes_no" style="question"
>       title="Credit Check">Does customer 6831 pass credit check?|
>       <actionid>990705990915</actionid>
>     </message-box>

Client Message Box Response DTD

The Client Message Box Response DTD describes the format of the XML document returned when a user is prompted for more information via a message dialog box. (The Client Message Box Request DTD describes the format of the XML document used to prompt the user.)

You can use the XPath function to extract the returned value. For example:

>     XPath("/message-box/attribute::option")
>     XPath("/message-box/@option")

The following sections describe the Client Message Box Response DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Description

- Template Definition DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Message Box Response DTD hierarchy.

Figure A-8 Client Message Box Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Message Box Response DTD, ClientMsgBoxResp.dtd.

>     <!ELEMENT message-box EMPTY>
>     <!ATTLIST message-box option (ok|yes|no|cancel) #REQUIRED>

Element Description

The following table describes the Client Message Box Response DTD element.

Table A-9 Client Message Box Response DTD Element

Element | Description | Example Value
--- | --- | ---
message-box | Root element. This element is empty. You must define the option attribute to specify the option entered by the user. This value can be ok, yes, no, or cancel. This attribute is required. | See Client Message Box Response DTD Example.

Client Message Box Response DTD Example

The following example illustrates a valid application of the Client Message Box Response DTD:

>     <message-box option=yes>
>     </message-box>

Client Request DTD

The Client Request DTD describes the format of the XML document that is returned by a subset of the runtime management methods described in Part IV, Run-Time Management.

The returned XML file contains details about all workflow and task updates that occurred as a consequence of the runtime method call. It may also contain requests for the client to handle. Such requests are generated as part of the ActionSendXMLToClient action, as described in Template Definition DTD.

The following sections describe the Client Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Entity Descriptions

Hierarchy Diagram

The following diagram illustrates the Client Request DTD hierarchy.

Figure A-9 Client Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Request DTD, ClientReq.dtd.

>     <!ENTITY callpgm   SYSTEM "ClientCallPgmReq.dtd">
>     <!ENTITY calladdin SYSTEM "ClientCallAddInReq.dtd">
>     <!ENTITY msgbox    SYSTEM "ClientMsgBoxReq.dtd">
>     <!ENTITY setvars   SYSTEM "ClientSetVarsReq.dtd">

>     <!ELEMENT wlpiresponse (instanceid, templatedefinitionid,
>     	(call-program | call-addin | set-variables |  message-box |
>     	custom)*)>
>     <!ELEMENT instanceid (#PCDATA)>
>     <!ELEMENT templatedefinitionid (#PCDATA)>
>     &callpgm;
>     &calladdin;
>     &msgbox;
>     &setvars;
>     <!ELEMENT custom ANY>

Element Descriptions

The following table describes the elements of the Client Request DTD.

Table A-10 Client Request DTD Elements

Element | Description | Example Value
--- | --- | ---
call-addin | Request for client to call a java addin that is compliant with the Client Call Addin Request DTD. | See Client Call Addin Request DTD Example.
call-program | Request for client to call an external program that is compliant with the Client Call Program Request DTD. | See Client Call Program Request DTD Example.
custom | Custom request consisting of any combination of elements and text. |
instanceid | ID of the workflow instance that is the target of the response document. | <instanceid> 3 </instanceid>
message-box | Request for client to respond to a message that is compliant with the Client Message Box Request DTD. | See Client Message Box Request DTD Example.
set-variables | Request for client to set variables that is compliant with the Client Set Variables Request DTD. | See Client Set Variables Request DTD Example.
templatedefinitionid | ID of the workflow template definition that is the target of the response document. | <templatedefinitionid> 2 </templatedefinitionid>
wlpiresponse | Root element. You must define the following subelements: wlpiresponse instanceid templatedefinitionid call-program | call-addin | set-variables | message-box | custom (zero or more) |

Entity Descriptions

The following table describes the Client Request DTD entities.

Table A-11 Client Request DTD Entities

Element | Meaning
--- | ---
calladdin | Client Call Addin Request DTD, ClientCallAddInReq.dtd
callpgm | Client Call Program Request DTD, ClientCallPgmReq.dtd
msgbox | Client Message Box Request DTD, ClientMsgBoxReq.dtd
setvars | Client Set Variables Request DTD, ClientSetVarsReq.dtd

Client Set Variables Request DTD

The Client Set Variables Request DTD describes the format of the XML document that is used to: (a) prompt a user to set variables via a dialog box; and (b) retrieve the response. (The Client Set Variables Response DTD describes the format of the returned value.) XML documents compliant with the Client Set Variables Request DTD can be passed when a template definition is created, as part of the ActionSendXMLToClient action. For details, see Template Definition DTD.

The following sections describe the Client Set Variables Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Client Set Variables Request DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Set Variables Request DTD hierarchy.

Figure A-10 Client Set Variables Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Set Variables Request DTD, ClientSetVarsReq.dtd.

>     <!ELEMENT set-variables (actionid, variable+)>
>     <!ATTLIST set-variables title CDATA #IMPLIED>
>     <!ELEMENT actionid (#PCDATA)>
>     <!ELEMENT variable (#PCDATA)>
>     <!ATTLIST variable name NMTOKEN #REQUIRED
>                        prompt NMTOKEN #IMPLIED>

Element Descriptions

The following table describes the elements of the Client Set Variables Request DTD.

Table A-12 Client Set Variables Request DTD Elements

Element | Description | Example Value
--- | --- | ---
actionid | Action ID. | <actionid> 991408825931 </actionid>
set-variables | Root element. You must define the following subelements: actionid variable (one or more) You can also define the title attribute to specify the text that appears in the title field of the set variables box. This attribute is optional. | See Client Set Variables Request DTD Example.
variable | Variable to be set. You must define the following attributes: name: Name of the variable to be set, specified in XML name token (NMTOKEN) format. This attribute is required. prompt: Text displayed in a dialog box as a cue to the user, specified in XML name token (NMTOKEN) format. This attribute is optional. | <variable name="ShipToState" prompt="An error has occurred in processing this order. Please enter the valid US state abbreviation for shipping:"> </variable>

Client Set Variables Request DTD Example

The following example illustrates a valid application of the Client Set Variables Request DTD.

>     <set-variables title="Error Warning">
>       <actionid>991408825931</actionid>
>       <variable name="ShipToState" prompt="An error has occurred in
>       processing this order. Please enter the valid US state
>       abbreviation for shipping:"></variable>
>     </set-variables>

Client Set Variables Response DTD

The Client Set Variables Response DTD describes the format of the XML document returned when prompting a user for more information via a set-variables dialog box. (The Client Set Variables Request DTD describes the format of the XML document used when prompting the user.)

You can use the XPath function to extract the returned value. For example:

>     XPath("/set-variables/child::variable[attribute::name=
>           "<var-name>"]/child::text()")
>     XPath("/set-variables/variable[@name="<var-name>"]/text()")

The following sections describe the Client Set Variables Response DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Description

- Client Set Variables Response DTD Example

Hierarchy Diagram

The following diagram illustrates the Client Set Variables Response DTD hierarchy.

Figure A-11 Client Set Variables Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Client Set Variables Response DTD, ClientSetVarResp.dtd.

>     <!ELEMENT set-variables (variable+)>
>     <!ELEMENT variable (#PCDATA)>
>     <!ATTLIST variable name NMTOKEN #REQUIRED>

Element Descriptions

The following table describes the elements of the Client Set Variables Response DTD.

Table A-13 Client Set Variables Response DTD Elements

Element | Description | Example Value
--- | --- | ---
set-variables | Root element. You must define one or more variable subelements. | See Client Set Variables Response DTD Example.
variable | Variable value. You must define the name attribute specifying the name of the variable that was set in XML name token (NMTOKEN) format. This attribute is required. | <variable name="ShipToState"> CA </variable>

Client Set Variables Response DTD Example

The following example illustrates a valid application of the Client Set Variables Response DTD:

>     <set-variables>
>       <variable name="ShipToState">CA</variable>
>     </set-variables>

Import Response DTD

The Import Response DTD describes the format of the XML document returned when the importPackage() method to the com.bea.wlpi.server.admin.Admin interface is called. For more information about the importPackage() method, Importing a Package of Publishable Objects.

The following sections describe the Import Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Import Response DTD hierarchy.

Figure A-12 Import Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Import Response DTD, ImportResp.dtd.

>     <!ELEMENT messages (title?, message*>
>     <!ELEMENT title (text, parm*)>
>     <!-- msg-num refers to an internationalized message number in Messages.properties -->
>     <!ATTLIST text msg-num NUMBER #REQUIRED>
>     <!-- the text value is simply the message formatted in the locale of the server -->
>     <!ELEMENT text (#PCDATA)>
>     <!ELEMENT message (text, parm*)>
>     <!-- each parm element represents a replaceable parameter value to insert
>     into the corresponding parameter marker in the localized message -->
>     <!ELEMENT parm (#PCDATA)>
>     <!-- type refers to an internationalized object type in Messages.properties -->
>     <!ATTLIST parm type NUMBER #IMPLIED>

Element Descriptions

The following table describes the elements of the Import Response DTD.

Table A-14 Import Response DTD Elements

Element | Description
--- | ---
message | Single message. You must define the following subelements: text parm (zero or more)
messages | List of messages. You must define the following subelements: title (zero or one) message (zero or more)
parm | Parameter value with which to replace the corresponding parameter marker in the localized message. You can define the following attribute. type: Parameter type.
text | Message formatted in the locale of the server. You must define the following attribute. msg-num: Message number.
title | Title for the message list. You must define the following subelements: text parm (zero or more)

Statistics Request DTD

The Statistics Request DTD describes the format of the XML document that is used when runtime statistics reports are generated. (The Statistics Response DTD describes the format of the returned statistics report.) For information about the method used to generate runtime statistics, see Querying the Run-Time Statistics.

The following sections describe the Statistics Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Statistics Request DTD hierarchy.

Figure A-13 Statistics Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Statistics Request DTD, StatisticsReq.dtd.

>     !ELEMENT statisticsrequest (org, templatedefinition,
>                                 tasks, (from, to)?, include, group)>
>     <!ELEMENT tasks (task*)>
>     <!ELEMENT task (name, id)>
>     <!ELEMENT include (#PCDATA, user* | role*)>
>     <!ELEMENT org (#PCDATA)>
>     <!ELEMENT templatedefinitionid (#PCDATA)>
>     <!ELEMENT name (#PCDATA)>
>     <!ELEMENT id (#PCDATA)>
>     <!ELEMENT from (#PCDATA)>
>     <!ELEMENT to (#PCDATA)>
>     <!ELEMENT user (#PCDATA)>
>     <!ELEMENT role (#PCDATA)>
>     <!ELEMENT group (#PCDATA)>

Element Descriptions

The following table describes the elements of the Client Set Variables Response DTD.

Table A-15 Statistics Request DTD Elements

Element | Description
--- | ---
from | Date from which the statistics report should be generated. This date must be specified using the following format: yyyyMMddHHmm, where yyyy specifies the year, MM specifies the month, dd specifies the day, HH specifies the hour, and mm specifies the minutes.
group | Boolean flag specifying whether or not to group the totals.
id | ID of the task to include in the report.
include | List of users and/or roles to include in the report. You can define the following subelements: user (zero or more) role (zero or mroe)
name | Name of task to include in thes report.
org | Organization for which you are generating a report.
r ole | Name of role to include in the report.
statisticsrequest | Root element. You must define the following subelements: org templatedefinitionid tasks (from, to) (zero or one) include group
task | Task to include in the report. You must define the following subelements: name id
tasks | List of tasks to include in the report. You must define zero or more occurrences of the following subelement: task
templatedefinitionid | ID of the template definition for which you are generating a report.
to | Entity date of the period for which the statistics report should be generated. This date must be specified using the following format: yyyyMMddHHmm, where yyyy specifies the year, MM specifies the month, dd specifies the day, HH specifies the hour, and mm specifies the minutes.
user | Name of user to include in the report.

Statistics Response DTD

The Statistics Response DTD describes the format of the XML document returned when runtime statistics are queried. (The Statistics Request DTD describes the format of the XML document used to request the query.) For information about gathering runtime statistics, see Querying the Run-Time Statistics.

The following sections describe the Statistics Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Statistics Response DTD hierarchy.

Figure A-14 Statistics Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Statistics Response DTD, StatisticsResp.dtd.

>     <!ELEMENT statistics (item*)>
>     <!ELEMENT item (task, user?, number, total, average, stddev,
>               min, max)>
>     <!ELEMENT task (#PCDATA)>
>     <!ELEMENT user (#PCDATA)>
>     <!ELEMENT number (#PCDATA)>
>     <!ELEMENT total (#PCDATA)>
>     <!ELEMENT average (#PCDATA)>
>     <!ELEMENT stddev (#PCDATA)>
>     <!ELEMENT min (#PCDATA)>
>     <!ELEMENT max (#PCDATA)>

Element Descriptions

The following table describes the elements of the Statistics Response DTD.

Table A-16 Statistics Response DTD Elements

Element | Description
--- | ---
average | Average amount of time spent performing a task.
item | Item for which you are gathering the workload report. You must define the following subelements: task user (zero or one) number total average stddev min max
max | Maximum amount of time spent performing a task.
min | Minimum amount of time spent performing a task.
number | Number of tasks performed.
statistics | Root element. You must define zero or more occurrences of the following subelement: item
stddev | Standard deviation of the times spent performing a task; indicates how much the AVERAGE truly represents the numbers upon which it was calculated.
task | Task upon which the following are calculated.
total | Total amount of time spent performing a task.
user | User that performed the task.

Template DTD

The Template DTD describes the format of the XML document that is used to create a workflow template. For information about creating workflow templates, see Creating and Managing Workflow Templates.

The following sections describe the Template DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Template DTD hierarchy.

Figure A-15 Template DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Template DTD, Template.dtd.

>     <!ELEMENT template (templateId, name, plugins?)>
>     <!ELEMENT plugins (plugin*)>
>     <!ELEMENT plugin (plugin-data)>
>     <!ATTLIST plugin
>       name CDATA #REQUIRED
>       major-version CDATA #REQUIRED
>       minor-version CDATA #REQUIRED
>       vendor CDATA #REQUIRED
>       url CDATA>
>     <!ELEMENT plugin-data ANY>
>     <!ATTLIST plugin-data
>         name CDATA #REQUIRED
>         id CDATA #REQUIRED
>     >
>     <!ELEMENT templateId #PCDATA>
>     <!ELEMENT name #PCDATA>

Element Descriptions

The following table describes the elements of the Template DTD.

Table A-17 Template DTD Elements

Element | Description
--- | ---
name | Name of the template.
plugin | Plug-in entry. One element appears for each plug-in referenced by a template, and for each plug-in that defines its own template property. Optionally, you can define the following subelement: plugin-data. You must define the following attributes: name: Plug-in name major-version: Major version of the plug-in software minor-version: Minor version of the plug-in software vendor: Vendor name url: URL (defaults to an empty string) For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration.
plugin-data | Plug-in data consisting of any combination of elements and text. You must define the following attributes: name: Name of the plug-in. This attribute is required. ID: Unique ID, provided by the plug-in, for the associated value object. This attribute is required. For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration.
plugins | Plug-in definition, used only if plug-in is provided. You can define zero or more occurrences of the following subelements: plugin For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration.
template | Root element. You must define the following subelements: templateId name plugins (zero or one)
templateId | ID of the template.

Template Definition DTD

The Template Definition DTD describes the format of the XML document that is used to create a workflow template definition. For information about creating workflow template definitions, see Creating and Managing Workflow Template Definitions.

The following sections describe the Template Definition DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

- Entity Descriptions

- Template Definition DTD Example

Hierarchy Diagram

The following diagram illustrates the Template Definition DTD hierarchy.

Figure A-16 Template Definition DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Template Definition DTD, TemplateDefinition.dtd.

Note: Descriptions of the DTD elements are provided in the table Template Definition DTD Elements. Descriptions of the DTD entities are provided in the table Template Definition DTD Entities.

>     <!ELEMENT Workflow (name, effective, changedby, changeddate, notes,
>                         idexpression, active, audit-enabled, plugins?, nodes,
>                         variables, error-handlers?)>
>     <!ATTLIST Workflow
>         major-version   CDATA  "1"
>         minor-version   CDATA  "0"
>         build-number    CDATA  "0"
>     >

>     <!ENTITY % node "id, x, y, notes">

>     <!ENTITY % std-action-types "
>         ActionAuditEntry |
>         ActionBusinessOperation |
>         ActionCallProgram |
>         ActionCancelEvent |
>         ActionCondition |
>         ActionExpression |
>         ActionNoOp |
>         ActionPostXMLEvent |
>         ActionPlugin |
>         ActionSendEMail |
>         ActionSendXMLToClient |
>         ActionTaskAssignRole |
>         ActionTaskAssignRoutingTable |
>         ActionTaskAssignUser |
>         ActionTaskDoit |
>         ActionTaskDone |
>         ActionTaskDueDate |
>         ActionTaskSetComment |
>         ActionTaskSetPriority |
>         ActionTaskUnassign |
>         ActionTaskUndo |
>         ActionTimedEvent |
>         ActionWorkflowAbort |
>         ActionWorkflowDone |
>         ActionWorkflowSetComment |
>         ActionWorkflowStart |
>         ActionXSLTransform
>     ">

>     <!ENTITY % action-types "%std-action-types; | ActionInvokeErrorHandler |
>                              ActionSetErrorHandler">

>     <!ENTITY % commit-action-types "%std-action-types; | ActionExitErrorHandler |
>                                     ActionSetErrorHandler">

>     <!ENTITY % rollback-action-types "ActionAuditEntry | ActionBusinessOperation |
>                                       ActionCallProgram | ActionCondition |
>                                       ActionExitErrorHandler |
>                                       ActionExpression | ActionNoOp | ActionPlugin |
>                                       ActionPostXMLEvent | ActionSendEMail |
>                                       ActionSendXMLToClient">

>     <!-- Ambiguous definition of element 'actions'. -->
>     <!-- In context 'Task' it is:
>          <!ELEMENT actions (created, activated, executed, markeddone)> -->
>     <!-- In context 'Decision', 'ActionCondition' it is:
>          <!ELEMENT actions (false, true)> -->
>     <!-- In context 'Done', 'Event', 'Start', 'ActionTaskDueDate',
>          'ActionTimedEvent', 'ActionWorkflowStart' it is:
>          <!ELEMENT actions (%action-types;)*> -->

>     <!ELEMENT actions ((created, activated, executed, markeddone)
>                      | (false, true)
>                      | (%action-types;)*)>
>     <!ELEMENT ActionAuditEntry (notes, audittext)>
>     <!ELEMENT ActionBusinessOperation (notes, descriptorid, description,
>                                        result, result-type, instance-variable,
>                                        instance-variable-type, parms,
>                                        iviewx?, iviewy?)>
>     <!ELEMENT ActionCallProgram (notes, program, arguments)>
>     <!ELEMENT ActionCancelEvent (notes, target)>
>     <!ELEMENT ActionCondition (notes, condition, actions)>

>     <!ELEMENT ActionExitErrorHandler (notes)>
>     <!ATTLIST ActionExitErrorHandler exit-type (rollback|stop|retry|continue)
>                                                 "rollback">

>     <!ELEMENT ActionExpression (notes, variable, (expression | xml)>

>     <!ELEMENT ActionInvokeErrorHandler (notes, xml?)>
>     <!ATTLIST ActionInvokeErrorHandler error-handler-name CDATA #REQUIRED>

>     <!ELEMENT ActionNoOp (notes, description)>

>     <!ELEMENT ActionPlugin (id, notes, plugin-data, actions*)>
>     <!-- description is displayed in action lists if the plugin is unavailable. -->
>     <!ATTLIST ActionPlugin description CDATA #REQUIRED>

>     <!ELEMENT ActionPostXMLEvent (notes, (topic | queue), transaction, addressees?,
>                                   message-properties?, delivery-mode,
>                                   priority, time-to-live, orderkey?
>                                  (variable | xml)),
>                                  iviewx?, iviewy?>
>     <!ELEMENT ActionSendEmail (notes, subject, message, to, cc, bcc)>
>     <!ELEMENT ActionSendXMLToClient (id, notes, xml, variables. iviewx?, iviewy?)>

>     <!ELEMENT ActionSetErrorHandler (notes)>
>     <!ATTLIST ActionSetErrorHandler error-handler-name CDATA #REQUIRED>

>     <!ELEMENT ActionTaskAssignRole (notes, target, role, expression)>
>     <!ELEMENT ActionTaskAssignRoutingTable (notes, target, routeconditions)>
>     <!ELEMENT ActionTaskAssignUser (notes, target, user, expression, role)>
>     <!ELEMENT ActionTaskDoIt (notes, target)>
>     <!ELEMENT ActionTaskDone (notes, target)>
>     <!ELEMENT ActionTaskDueDate (id, notes, target, expression, calendartype,
>                                  calendarname, actions)>
>     <!ELEMENT ActionTaskSetComment (notes, target, comment)>
>     <!ELEMENT ActionTaskSetPriority (notes, target, priority)>
>     <!ELEMENT ActionTaskUnassign (notes, target)>
>     <!ELEMENT ActionTaskUndo (notes, target)>
>     <!ELEMENT ActionTimedEvent (id, notes, expression, calendartype, executionunits,
>                                 scheduleunits, executiontime, scheduletime, recoverable?
>                                 stopwhentaskdone, usetimeexpression, actions)>
>     <!ELEMENT ActionWorkflowAbort (notes)>
>     <!ELEMENT ActionWorkflowDone (notes)>
>     <!ELEMENT ActionWorkflowSetComment (notes, comment)>
>     <!ELEMENT ActionWorkflowStart (id, notes, templateid, template-name, refvariable,
>                                    orgexpression, parameters, results, actions,
>                                    iviewx?, iviewy?)>
>     <!ELEMENT ActionXSLTransform (notes, input-expression, transform-document,
>                                   transform-source, output-variable,
>                                   xsl-parameters?)>
>     <!ELEMENT xsl-parameters (xsl-parameter+)>
>     <!ELEMENT xsl-parameter (name, expression)>
>     <!ELEMENT activated ((%action-types;)*)>
>     <!ELEMENT addressee (name, expression, type)>
>     <!ELEMENT addressees (instanceid)
>     <!ELEMENT bcc (addressee*)>
>     <!ELEMENT cc (addressee*)>
>     <!ELEMENT commit-actions ((%commit-action-types;)*)>
>     <!ELEMENT created ((%action-types;)*)>
>     <!ELEMENT Decision (%node;, condition, truenexts, falsenexts, actions)>
>     <!ELEMENT Done (%node;, actions, plugin-data?)>
>     <!ELEMENT Event (%node;, ((root, description, key, condition) | (plugin-data)),
>                      actions, variables, ivewx?, iviewy?)>
>     <!ELEMENT error-handlers (error-handler*)>
>     <!ELEMENT error-handler (notes, variables, commit-actions, rollback-actions)>
>     <!-- No more than one error-handler can have initial set to true -->
>     <!ATTLIST error-handler
>         name    CDATA        #REQUIRED
>         initial (true|false) "false"
>     >

>     <!ELEMENT executed ((%action-types;)*)>
>     <!ELEMENT false ((%action-types;)*)>
>     <!ELEMENT falsenexts (next*)>
>     <!ELEMENT Join (%node;, and)>
>     <!ELEMENT markeddone ((%action-types;)*)>
>     <!ELEMENT message-properties (property+)>
>     <!ELEMENT nexts (next*)>
>     <!ELEMENT nodes (Decision | Done | Event | Join | Start | Task)*>
>     <!ELEMENT parameters (parm*)>

>     <!-- Ambiguous definition of element 'parm' -->
>     <!-- In context 'ActionBusinessOperation' it is <!ELEMENT parm (#PCDATA)> -->
>     <!-- In context 'ActionWorkflowStart' it is <!ELEMENT parm (name, value)> -->
>     <!-- N.B. Content model shows repeatable elements purely to conform
>          with DTD syntax. -->
>     <!-- <parm> elements only appear in the two forms exemplified above. -->
>     <!ELEMENT parm ((#PCDATA | (name, value))*)>
>     <!ELEMENT parms (parm*)>

>     <!-- The 'plugins' element appears if the template definition uses
>          plugin functionality or any plugin defines its own template
>          definition property. -->
>     <!-- The Studio is responsible for updating this element when
>          saving the definition. -->
>     <!ELEMENT plugins (plugin*)>
>     <!-- One 'plugin' element appears for each plugin referenced by a
>          template definition and each plugin which defines its own template
>         definition property. -->
>     <!ELEMENT plugin (plugin-data?)>
>     <!-- name is the plugin name, referenced means whether this template
>          definition uses this plugin-specific functionality, version
>          is the plugin version number. -->
>     <!ATTLIST plugin
>         name CDATA #REQUIRED
>         referenced (true|false) #REQUIRED
>         major-version CDATA #REQUIRED
>         minor-version CDATA #REQUIRED
>         vendor CDATA #REQUIRED
>         url CDATA ""
>     >
>     <!ELEMENT property (name, value)>
>     <!-- Ambiguous definition of element 'result'. -->
>     <!-- In context 'ActionBusinessOperation' it is <!ELEMENT result (#PCDATA)> -->
>     <!-- In context 'ActionWorkflowStart' it is <!ELEMENT result (name, value)> -->
>     <!ELEMENT result ((#PCDATA | (name, value))*)>
>     <!ELEMENT results (result*)>
>     <!ELEMENT rollback-actions ((%rollback-action-types;)*)>
>     <!ELEMENT routecondition (to, type, condition)>
>     <!ELEMENT routeconditions (routecondition*)>
>     <!ELEMENT Start (%node;, description, (manual
>                                          | called
>                                          | (timed, dateexpression,
>                                             reschedamount, reschedunits,
>                                             recoverable?, calendarname, startorg)
>                                          | (event, root, key, condition, startorg)
>                                          | (plugin-data, startorg)),
>                      nexts, actions, variables,iviewx?, iviewy?)>
>     <!ELEMENT plugin-data ANY>
>     <!-- name is the plugin name,
>          id is the plugin-provided unique ID for the xxxInfo object. -->
>     <!ATTLIST plugin-data
>         name CDATA #REQUIRED
>         ID CDATA #REQUIRED
>     >
>     <!ELEMENT Task (%node;, name, priority, donewithoutdoit, doitifdone,
>                     unmarkdone, modifiable, reassignment, nexts, actions)>
>     <!ELEMENT to (addressee*)>
>     <!ELEMENT true ((%action-types;)*)>
>     <!ELEMENT truenexts (next*)>

>     <!-- Ambiguous definition of element 'variable' -->
>     <!-- In context 'Workflow' it is
>          <!ELEMENT variable (name, notes, (type|plugin-data), xmltype,
>                              inmandatory, in, out)> -->
>     <!-- In context 'Start', 'ActionSendXMLToClient' it is
>          <!ELEMENT variable (name, expression)> -->
>     <!-- In context 'ActionExpression' it is
>          <!ELEMENT variable (#PCDATA)> -->
>     <!-- N.B. Content model shows repeatable elements purely to conform to
>          DTD syntax. -->
>     <!-- <variable> elements only appear in the three forms exemplified above. -->
>     <!ELEMENT variable (((name, notes, (type|plugin-data), xmltype, inmandatory,
>                           in, out)
>                       |  (name, expression)
>                       |  (#PCDATA))*)>
>     <!--ELEMENT variable (#PCDATA)-->
>     <!ELEMENT variables (variable*)>

>     <!ELEMENT active (#PCDATA)>
>     <!ELEMENT and (#PCDATA)>
>     <!ELEMENT arguments (#PCDATA)>
>     <!ELEMENT audit-enabled (#PCDATA)>
>     <!ELEMENT audittext (#PCDATA)>
>     <!ELEMENT calendarname (#PCDATA)>
>     <!ELEMENT calendartype (#PCDATA)>
>     <!ELEMENT called (#PCDATA)>
>     <!ELEMENT changedby (#PCDATA)>
>     <!ELEMENT changeddate (#PCDATA)>
>     <!ELEMENT comment (#PCDATA)>
>     <!ELEMENT condition (#PCDATA)>
>     <!ELEMENT correlationid (#PCDATA)>
>     <!ELEMENT dateexpression (#PCDATA)>
>     <!ElEMENT delivery-mode (#PC-DATA)
>     <!ELEMENT description (#PCDATA)>
>     <!ELEMENT descriptorid (#PCDATA)>
>     <!ELEMENT doitifdone (#PCDATA)>
>     <!ELEMENT donewithoutdoit (#PCDATA)>
>     <!ELEMENT effective (#PCDATA)>
>     <!ELEMENT event (#PCDATA)>
>     <!ELEMENT executionunits (#PCDATA)>
>     <!ELEMENT executiontime (#PCDATA)>
>     <!ELEMENT expression (#PCDATA)>
>     <!ELEMENT id (#PCDATA)>
>     <!ELEMENT idexpression (#PCDATA)>
>     <!ELEMENT in (#PCDATA)>
>     <!ELEMENT inmandatory (#PCDATA)>
>     <!ELEMENT input-expression (#PCDATA)
>     <!ELEMENT instanceid (#PCDATA)>
>     <!ELEMENT instance-variable (#PCDATA)>
>     <!ELEMENT instance-variable-type (#PCDATA)>
>     <!ELEMENT iviewx (#PCDATA)
>     <!ELEMENT iviewy (#PCDATA)
>     <!ELEMENT jmstype (#PCDATA)
>     <!ELEMENT key (#PCDATA)>
>     <!ELEMENT manual (#PCDATA)>
>     <!ELEMENT message (#PCDATA)>
>     <!ELEMENT modifiable (#PCDATA)>
>     <!ELEMENT name (#PCDATA)>
>     <!ELEMENT next (#PCDATA)>
>     <!ELEMENT notes (#PCDATA)>
>     <!ELEMENT orderkey (#PCDATA)>
>     <!ELEMENT orgexpresion (#PCDATA)>
>     <!ELEMENT out (#PCDATA)>
>     <!ELEMENT output-variable (#PCDATA)
>     <!ELEMENT priority (#PCDATA)>
>     <!ELEMENT program (#PCDATA)>
>     <!ELEMENT queue (#PCDATA)>
>     <!ATTLIST queue expression (true | false) "false"
>     <!ELEMENT reassignment (#PCDATA)>
>     <!ELEMENT recoverable (#PCDATA)>
>     <!ELEMENT refvariable (#PCDATA)>
>     <!ELEMENT replyto (#PCDATA)
>     <!ELEMENT reschedamount (#PCDATA)>
>     <!ELEMENT reschedunits (#PCDATA)>
>     <!ELEMENT result-type (#PCDATA)>
>     <!ELEMENT role (#PCDATA)>
>     <!ELEMENT root (#PCDATA)>
>     <!ELEMENT scheduletime (#PCDATA)>
>     <!ELEMENT scheduleunits (#PCDATA)>
>     <!ELEMENT startorg (#PCDATA)>
>     <!ATTLIST startorg expression (true | false) "true"
>     <!ELEMENT stopwhentaskdone (#PCDATA)>
>     <!ELEMENT subject (#PCDATA)>
>     <!ELEMENT target (#PCDATA)>
>     <!ELEMENT templateid (#PCDATA)>
>     <!ELEMENT template-name (#PCDATA)>
>     <!ELEMENT time-to-live (#PCDATA)>
>     <!ELEMENT timed (#PCDATA)>
>     <!ELEMENT topic (#PCDATA)>
>     <!ATTLIST topic expression (true | false) "false")
>     <!ELEMENT type (#PCDATA)>
>     <!-- The 'transaction' element has the value 'true' or 'false'. -->
>     <!ELEMENT transaction (#PCDATA)
>     <!ELEMENT transform-document (#PCDATA)
>     <!ELEMENT transform-source (#PCDATA)
>     <!ELEMENT unmarkdone (#PCDATA)>
>     <!ELEMENT user (#PCDATA)>
>     <!ELEMENT usetimeexpression (#PCDATA)>
>     <!ELEMENT value (#PCDATA)>
>     <!ELEMENT x (#PCDATA)>
>     <!ELEMENT xml ANY>
>     <!ELEMENT xmltype (#PCDATA)>
>     <!ELEMENT y (#PCDATA)>

Element Descriptions

The following table describes the elements of the Template Definition DTD.

Table A-18 Template Definition DTD Elements

Element | Description | Example Value
--- | --- | ---
ActionAuditEntry | Action used to define audit entries that are published to the JMS wlpiAudit topic, in addition to the default audit entries that include major interactions and/or changes. In the Studio, you define this action by selecting Make Audit Entry within the Miscellaneous actions category of the Add Actions dialog box. You must define the following subelements: notes audittext | <ActionAuditEntry> <notes></notes> <audittext> &quot;Workflow cancelled.&quot; </audittext> </ActionAuditEntry>
ActionBusinessOperation | Action used to invoke predefined business operations on an EJB or Java class. The results of invoking the business operation can be assigned to workflow variables. In the Studio, you configure business operations by selecting Business Operations from the Configuration menu. You invoke them, when defining actions, by selecting Perform Business Operation within the Integration actions category of the Add Actions dialog box. You must define the following subelements: notes descriptorid description result result-type instance-variable instance-variable-type parms iviewx (zero or one) iviewy (zero or one) | <ActionBusinessOperation> <notes> This is a note. </notes> <descriptorid> 1 </descriptorid> <description> Check Inventory </description> <result> Inventory </result> <result-type> integer </result-type> <instance-variable> PobeanHandle </instance-variable> <instance-variable-type> session </instance-variable-type> <parms> <parm> ItemNumber </parm> </parms> <iviewx>150</iviewx> <iviewy>70</iviewy> </ActionBusinessOperation>
ActionCallProgram | Action used to invoke predefined executable program. The results of invoking the program can be assigned to workflow variables. In the Studio, you define this action by selecting Call Program within the Integration actions category of the Add Actions dialog box. You must define the following subelements: notes program arguments | <ActionCallProgram> <notes> This is a note. </notes> <program> ProgramA </program> <arguments> CurrentUser() </arguments> </ActionCallProgram>
ActionCancelEvent | Action used to cancel a workflow event that is defined within a workflow. In the Studio, you define this action by selecting Cancel Workflow Event within the Miscellaneous actions category of the Add Actions dialog box. You must define the following subelements: notes target | <ActionCancelEvent> <notes> This is a note. </notes> <target> 987445252339 </target> </ActionCancelEvent>
ActionCondition | Action used to evaluate a conditional expression at run time and depending on the result, to perform alternative sequences of subactions. In the Studio, you define this action by selecting Evaluate Condition within the Miscellaneous actions category of the Add Actions dialog box. You must define the following subelements: notes condition actions | <ActionCondition> <notes> This is a note. </notes> <condition> CurrentUser()= &quot;joe&quot; </condition> <actions> <ActionTaskUnassign> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskUnassign> </false> <true> <ActionTaskDone> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskDone> </actions> </ActionCondition>
ActionExitErrorHandler | Action used to exit an exception handler. In the Studio, you define this action using the Exit Exception Handler dialog box. You can access the dialog box by clicking the Add button in the Exception Handler Properties dialog box when the Actions on Commit or Actions on Rollback tab is selected. You must define the following subelement: notes You must specify one of the following values for the exit-type attribute to specify a method to be used by the existing error handler: rollback - Marks the user transaction as rollback only, returning the workflow to the state in which it existed prior to the start of the transaction. The exception is propagated to the client (if any) as a WorkflowException. In the rollback path, this is the only option available. Certain EJBs can either mark a transaction for rollback only, by calling a UserTransaction method, or they can throw an unchecked exception across a container boundary. In either case, WebLogic Server rolls back the transaction. stop - Exits the error handler and does not execute any follow-on actions. retry - Exits the error handler and attempts to retry the failed operation. (The failed operation is an action or the setting of a variable.) continue - Stops the execution of the exception handler and attempts to continue the execution of the workflow at the next operation. (The next operation is the next action to be performed or variable to be set.) | <ActionExitErrorHandler exit-type="rollback"> <notes> This is a note. </notes> </ActinoExitErrorHandler>
ActionExpression | Action used to set a workflow variable. In the Studio, you define this action by selecting Set Workflow Variable within the Workflow actions category of the Add Actions dialog box. You must define the following subelements: notes variable (expression | xml) | <ActionExpression> <notes> This is a note. </notes> <variable> CustomerState </variable> <expression> &quot;NJ&quot; </expression> </ActionExpression>
ActionInvokeErrorHandler | Action used to enable the invocation of the specified exception handler. Upon execution of this action, WebLogic Process Integrator sends the user-defined XML document to the exception processor and invokes the specified handler. In the Studio, you define this action by selecting Invoke Exception Handler within the Exception Handling Actions category of the Add Actions dialog box. You must define the following subelements: notes xml (zero or one) You must specify a text string specifying the name of a valid exception handler for the error-handler-name attribute. This attribute is required. | <ActionInvokeErrorHandler error-handler-name= "EH Wrong data to Pobean"> <notes> This is a note. </notes> </ActionInvokeErrorHandler>
ActionNoOp | Action used as a placeholder for a future action. This action performs no function. In the Studio, you define this action by selecting No Operation within the Miscellaneous actions category of the Add Actions dialog box. You must define the following subelements: notes description | <ActionNoOp> <notes> This is a note. </notes> <description> Replace with task assignment. </description> </ActionNoOp>
ActionPlugin | Generic container for all plug-in actions. You must define the following subelements: id plugin-data notes actions (zero or more) You must specify a text string providing a description of the plug-in the name for the label attribute. This attribute is required. Note: If a plug-in is available, the Studio displays the description of it in the actions lists. For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration. | <ActionPlugin label='Send Confirm Order Event'> <id>1000936287350 </id> <plugin-data name="com.bea.wlpi.SamplePlugin" ID="2"> <statusvariable> OrderStatus </statusvariable> <totalpricevariable> OrderTotalPrice </totalpricevariable> </plugin-data> <notes></notes> </ActionPlugin>
ActionPostXMLEvent | Action used to post an XML event. In the Studio, you define this action by selecting Post XML Event within the Integration actions category of the Add Actions dialog box. You must define the following subelements: notes topic | queue transaction addressees (zero or one) message-properties (zero or one) delivery-mode priority time-to-live orderkey (zero or one) variable | xml iviewx (zero or one) iviewy (zero or one) | <ActionPostXMLEvent> <notes> This is a note. </notes> <transaction> false </transaction> <delivery-mode> PERSISTENT </delivery-mode> <priority>4 </priority> <expression>false </expression> <time-to-live>0 </time-to-live> <xml> <order> &quot;new&quot; </order> </xml> <iviewx>240</iviewx> <iviewy>20</iviewy> </ActionPostXMLEvent>
actions | Action definition. For a Task node, you must define the following subelements: created activated executed markeddone For a Decision node or an ActionCondition action, you must define the following subelements: false true For a Done, Event, or Start node; or a ActionTaskDueDate, ActionTimedEvent, or ActionWorkflowStart event, you can define zero or more occurrences of the following subelement: %action-types | <actions> <created> </created> <activated> <ActionTaskAssignUser> <notes> This is a note. </notes> <target> 2 </target> <user>joe</user> <expression> false </expression> <role> false </role> </ActionTaskAssignUser> </activated> <executed> </executed> <markeddone> </markeddone> </actions>
ActionSendEMail | Action used to send an e-mail message to a WebLogic Process Integrator user or other individual. The internet standard SMTP protocol is used to transmit the message. In the Studio, you define this action by selecting Send E-mail Message within the Miscellaneous actions category of the Add Actions dialog box. You must define the following subelements: notes subject message to cc bcc | <ActionSendEMail> <notes> This is a note. </notes> <subject> &quot;Order &quot; </subject> <message> &quot;This is the message. &quot; </message> <to> <addressee> <name> joe@work </name> <expression> false </expression> <type> address </type> </addressee> </to> <cc> </cc> <bcc> </bcc> </ActionSendEMail>
ActionSendXMLToClient | Action used to send an XML document to the client, This action allows communication between the WebLogic Process Integrator and a client program via an XML message. In the Studio, you define this action by selecting Send XML to Client within the Integration actions category of the Add Actions dialog box. The XML document must be compliant with one of the following DTD formats, based on the request that is being sent: Client Call Addin Request DTD Client Call Program Request DTD Client Message Box Request DTD Client Set Variables Request DTD Custom clients can define their own services and XML formats. You must define the following subelements: id notes xml variables iviewx (zero or one) iviewy (zero or one) | <ActionSendXMLToClient> <id>959395846210</id> <notes>This is a note. </notes> <xml> <message-box title= "&quot;Order Confirmation&quot;" style="&quot;question &quot;" options= "&quot;yes_no&quot;"> &quot;Do you Confirm this order?&quot; <actionid> &quot;959395846210 &quot; </actionid> </message-box> </xml> <variables> <variable> <name> Confirm</name> <expression> XPath(&quot; /message-box/ attribute:: option&quot;) </expression> </variable> </variables> <actions> <ActionTaskDone> <notes> This is a note. </notes> <target>2</target> </ActionTaskDone> </actions> </ActionSendXMLToClient>
ActionSetErrorHandler | Action used to set a specified exception handler as active for a specific workflow template definition. This exception handler persists for the workflow instance until a subsequent ActionSetErrorHandler action is executed within the same workflow. By default, the system exception handler is used. In the Studio, you define this action by selecting Set Workflow Exception Handler within the Exception Handling Actions category of the Add Actions dialog box. You must define the following subelements: notes. You must specify a text string specifying the name of a valid exception handler (as a text string) for the error-handler-name attribute. This attribute is required. | <ActionSetErrorHandler error-handler-name= "EH Wrong data to Pobean"> <notes> This is a note. </notes> </ActionSetErrorHandler>
ActionTaskAssignRole | Action used to assign a task to a role. In the Studio, you define this action by selecting Assign Task to Role within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target role expression | <ActionTaskAssignRole> <notes> This is a note. </notes> <target> 963511923442 </target> <role> Role1 </role> <expression> false </expression> </ActionTaskAssignRole>
ActionTaskAssignRoutingTable | Action used to assign a task to a user or role, depending on a set of conditions. A condition specifies the circumstances under which a task should be assigned to a specific assignee (user or role). At runtime, the system selects the assignee associated with the condition that evaluates to true. In the Studio, you define this action by selecting Assign Task to Role within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target routeconditions | <ActionTaskAssignRoutingTable> <notes> This is a note. </notes> <target>2</target> <routeconditions> <routecondition> <to>Role1</to> <type> userinrole </type> <condition> a+b </condition> </routecondition> </routeconditions> </ActionTaskAssignRoutingTable>
ActionTaskAssignUser | Action used to assign a task to either a user or user in a role. When assigning a task to a user in a role, the process engine performs load balancing by reviewing the number of tasks assigned to all users in a role (that do not currently have reroutes in effect), indentifying the user with the smallest number of assigned tasks, and assigning the task to this user. In the Studio, you define this action by selecting Assign Task to User within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target user expression role | <ActionTaskAssignUser> <notes> This is a note. </notes> <target> 963511775400 </target> <user>joe</user> <expression> false </expression> <role> false </role> </ActionTaskAssignUser>
ActionTaskDoit | Action used to execute a task. In the Studio, you define this action by selecting Execute Task within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target | <ActionTaskDoIt> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskDoIt>
ActionTaskDone | Action used to mark task complete. This action sets the task completed value to the current date and time, and results in the sequential execution of all of the actions associated with the specified task's Marked Done event. In the Studio, you define this action by selecting Mark Task As Done within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target | <ActionTaskDone> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskDone>
ActionTaskDueDate | Action used to specify a task due date as an interval (expressed in minutes, hours, days, weeks, or months) from the point at which the action is executed. This action results in the execution of all actions associated with the Marked Done event. You can also define a set of actions to be performed if a task becomes overdue. In the Studio, you define this action by selecting Set Task Due Date within the Task Actions category of the Add Actions dialog box. You must define the following subelements: id notes target expression calendartype calendarname actions | <ActionTaskDueDate> <id>987445484073</id> <notes> This is a note. </notes> <target>2</target> <expression> DateAdd(Date(), &quot;m&quot;,1) </expression> <calendartype> 0 </calendartype> <calendarname> </calendarname> <actions> <ActionNoOp> <notes> This is a note. </notes> <description> Replace with task assignment. </description> </ActionNoOp> </actions> </ActionTaskDueDate>
ActionTaskSetComment | Action used to specify a comment to be displayed to the user at runtime when the action is executed. Comments typically contain explanatory text. In the Worklist, the comment is displayed as a free-form text message in the comment column. In the Studio, you define this action by selecting Set Task Comment within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target comment | <ActionTaskSetComment> <notes> This is a note. </notes> <target> 963511923442 </target> <comment> This is a comment. </comment> </ActionTaskSetComment>
ActionTaskSetPriority | Action used to set a task priority. In the Worklist, the comment is displayed as a free-form text message in the comment column. In the Studio, you define this action by selecting Set Task Priority within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target priority | <ActionTaskSetPriority> <notes> This is a note. </notes> <target> 963511923442 </target> <priority> 1 </priority> </ActionTaskSetPriority> [Sets priority to medium (1).]
ActionTaskUnassign | Action used to unassign a task. In the Studio, you define this action by selecting Set Task Priority within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target | <ActionTaskUnassign> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskUnassign>
ActionTaskUndo | Action used to mark task incomplete. The action does not result in the execution of the actions associated with the specified task's Activated event. In the Studio, you define this action by selecting Mark Task As Undone within the Task Actions category of the Add Actions dialog box. You must define the following subelements: notes target | <ActionTaskUndo> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskUndo>
ActionTimedEvent | Action used to create a timed event that is triggered at an exact time and date, and will execute any specified actions. In the Studio, you define this action by selecting Timed Event within the Miscellaneous Actions category of the Add Actions dialog box. You must define the following subelements: id notes expression calendartype executionunits scheduleunits executiontime scheduletime recoverable (zero or one) stopwhentaskdone usetimeexpression actions | <ActionTimedEvent> <id>987100768489</id> <notes> This is a note. </notes> <expression> DateAdd(Date(), &quot;m&quot;, 1) </expression> <calendartype>0 </calendartype> <executionunits>3 </executionunits> <scheduleunits>0 </scheduleunits> <executiontime>5 </executiontime> <scheduletime> </scheduletime> <recoverable> true </recoverable> <stopwhentaskdone> true </stopwhentaskdone> <usetimeexpression> true </usetimeexpression> <actions> <ActionTaskAssignUser> <notes> This is a note. </notes> <target>2 </target> <user>joe</user> <expression> false </expression> <role>false </role> </ActionTaskAssignUser </actions> </ActionTimedEvent>
active | Flag (true or false) specifying whether or not the workflow template definition is active. | <active> true </active>
activated | Actions associated with the task's Activated event. You can define zero or more occurrences of the following subelement: %action-types. | <activated> <ActionTaskAssignUser> <notes> This is a note. </notes> <target> 2 </target> <user>joe</user> <expression> false </expression> <role> false </role> </ActionTaskAssignUser> </activated>
ActionWorkflowAbort | Action used to abort a workflow. This action permanently stops a workflow and deletes it from the server. In the Studio, you define this action by selecting Abort Workflow within the Workflow Actions category of the Add Actions dialog box. You must define the following subelement: notes. | <ActionWorkflowAbort> <notes> This is a note. </notes> </ActionWorkflowAbort>
ActionWorkflowDone | Action used to mark a workflow as complete. In the Studio, you define this action by selecting Mark Workflow as Done within the Workflow Actions category of the Add Actions dialog box. You must define the following subelement: notes. | <ActionWorkflowDone> <notes> This is a note. </notes> </ActionWorkflowDone>
ActionWorkflowSetComment | Action used to specify a comment to be displayed to the user at runtime when the action is executed. Comments typically contain explanatory text. In the Studio, you define this action by selecting Mark Workflow as Done within the Workflow Actions category of the Add Actions dialog box. You must define the following subelements: notes comment | <ActionWorkflowSetComment> <notes> This is a note. </notes> <comment> &quot;Order Cancelled&quot; </comment> </ActionWorkflowSetComment>
ActionWorkflowStart | Action used to start a workflow, supporting subworkflows. In the Studio, you define this action by selecting Start Workflow within the Workflow Actions category of the Add Actions dialog box. You must define the following subelements: id notes templateid template-name refvariable orgexpression parameters results actions iviewx (zero or one) iviewy (zero or one) | <ActionWorkflowStart> <id> 987445540073 </id> <notes> This is a note. </notes> <templateid> 3 </templateid> <template-name> ShipBill </template-name> <refvariable> Name </refvariable> <parameters> </parameters> <results> </results> <actions> </actions> </ActionWorkflowStart>
ActionXSLTransform | Action used to perform an XML transformation. You must define the following subelements: notes input-expression transform-document transform-source output-variable xsl-parameters (one or more) |
addressee | Address of a receipient. You must define the following subelements: name expression type | <addressee> <name> joe@work </name> <expression> false </expression> <type> address </type> </addressee>
addressees | One or more addressees. You must define the following subelement: instanceid |
and | Flag specifying whether or not the Join node is an AND (true) or OR (false) node. | <and>true</and>
arguments | Valid workflow expression to be evaluated at runtime and passed to the called program defined by the program element. | <arguments> CurrentUser() </arguments>
audit-enabled | Flag (true or false) specifying whether or not auditing is enabled on the workflow template definition. | <audit-enabled> false </audit-enabled>
audittext | Audit entry expression to be sent to the audit listener for further retrieval at runtime. The audit entry can be an expression built with functions and workflow variables, or a string of text. | <audittext> &quot;Workflow cancelled.&quot; </audittext>
bcc | E-mail addresses of the individuals to be blind-copied on the e-mail message, as defined by the ActionSendEMail action. You can define zero or more occurrences of the following subelement: addressee. | <bcc> <addressee> <name> joe@work </name> <expression> false </expression> <type> address </type> </addressee> </bcc>
calendartype | Business calendar type. | <calendartype> Type1 </calendartype>
calendarname | Business calendar name. | <calendarname> MyCalendar </calendarname>
called | Flag (true or false) specifying whether or not the Start node is callable from another workflow. | <called> true </called>
cc | E-mail address(es) of the individuals to be copied on an e-mail message, as defined by the ActionSendEMail action. You can define zero or more occurrences of the following subelement: addressee. | <cc> <addressee> <name> joe@work </name> <expression> false </expression> <type> address </type> </addressee> </cc>
changedby | Valid user that last modified the workflow template definition. | <changedby> joe </changedby>
changeddate | Date at which the workflow template was changed, specified using the following format: yyyyMMddHHmm, where yyyy specifies the year, MM specifies the month, dd specifies the day, HH specifies the hour (00 through 23), and mm specifies the minutes. | <changeddate> 200103220930 </changeddate> [March 22, 2001 9:30AM]
comment | A valid workflow expression or text string that defines a comment and is evaluted at runtime. Comments typically contain explanatory text. | <comment> &quot;Order Cancelled&quot; </comment>
commit-actions | Actions performed when a transaction is committed. You can define zero or more occurrences of the following subelement: %commit-action-types. | <commit-actions> <ActionTaskDone> <notes> This is a note. </notes> <target> 963511775400 </target> </ActionTaskDone> </commit-actions>
condition | Valid workflow condition that is evaluated at runtime and determines which set of subactions to perform. | <condition> status=&quot; complete&quot; </condition>
correlationid | Correlation ID. |
created | Actions associated with the task's Created event. You can define zero or more occurrences of the following subelement: %action-types. | <created> <ActionTaskAssignUser> <notes> This is a note. </notes> <target> 2 </target> <user>joe</user> <expression> false </expression> <role> false </role> </ActionTaskAssignUser> </created>
dateexpression | Date to start a time-triggered workflow. This value can be either a workflow expression or a text string, and should result in the following format: yyyyMMddHHmm, where yyyy specifies the year, MM specifies the month, dd specifies the day, HH specifies the hour (00 through 23), and mm specifies the minutes. | <dateexpression> 200007120000 </dateexpression> [July 12, 2000 12:00 am]
Decision | Decision node. You must define the following subelements: %node condition truenexts falsenexts actions | See Template Definition DTD Example.
delivery-mode | Mode used to deliver a posted XML event. | <delivery-mode> PERSISTENT </delivery-mode>
description | Text description of the element. | <description> Start </description>
descriptorid | Descriptor ID of the business operation that is being defined for the ActionBusinessOperation action. | <descriptorid> 31 </descriptorid>
doitifdone | Permission flag (true or false) specifying whether or not the task can be executed once it has been marked done, using the methods described in Executing a Task. | <doitifdone> true </doitifdone>
Done | Done node. For manually started workflows, you must define the following subelements: %node description actions plugin-data (zero or one) | See Template Definition DTD Example.
donewithoutdoit | Permission flag (true or false) specifying whether or not the task can be marked done without having been executed, using the methods described in Marking a Task as Complete or Incomplete. | <donewithoutdoit> true </donewithoutdoit>
effective | Effective date in the following format: yyyyMMddHHmm, where yyyy specifies the year, MM specifies the month, dd specifies the day, HH specifies the hour (00 through 23), and mm specifies the minutes. | <effective> 200007120000 </effective> [July 12, 2000 12:00 am]
error-handler | Error handler. You must define the following subelements: notes variables commit-actions rollback-actions You define the following attributes: name: Error-handler name. initial: Flag (true or false) specifying whether or not this is the default error handler to use. This attribute can be set to true for only one error handler. This attribute defaults to false. | <error-handler name="EH Wrong data to Pobean" initial="false"> <notes> This is a note. </notes> <variables> </variables> <commit-actions> <ActionExitErrorHandler exit-type="continue"> <notes> This is a note. </notes> </ActionExitErrorHandler> </commit-actions> <rollback-actions> <ActionPostXMLEvent> <notes>Notes. </notes> <xml> <order> &quot;new&quot; </order> </xml> </ActionPostXMLEvent> <ActionExitErrorHandler exit-type="rollback"> <notes>Notes. </notes> </ActionExitErrorHandler> </rollback-actions> </error-handler>
error-handlers | Error handlers defined for the workflow template definition. You must define the following subelement: error-handler. | <error-handlers> <error-handler> ... </error-handler> </error-handlers>
Event | Event node. For a standard Event node, you must define the following subelements: %node root description key condition actions variables iviewx (zero or one) iviewy (zero or one) For a plugin Event node, you must define the following subelements: %node plugin-data actions variables iviewx (zero or one) iviewy (zero or one) | See Template Definition DTD Example.
event | Flag (true or false) specifying whether or not the Start node is event-triggered. | <event> true </event>
executed | Actions associated with the task's Executed event. You can define zero or more occurrences of the following subelement: %action-types. | <executed> <ActionTaskDone> <notes> This is a note. </notes> <target> 963511923442 </target> </ActionTaskDone> </executed>
executiontime | Numeric value specifying the number of executionunits units from the current time, that define the amount of time that must elapse before a time-triggered event (defined by the ActionTimedEvent action) is executed. | <executiontime> 5 </executiontime>
executionunits | Units used to express the execution time. Possible values include: 0: Milliseconds 1: Seconds 2: Minutes 3: Hours 4: Days 5: Weeks 6: Months 7: Business hours 8: Business days | <executionunits> 3 </executionunits>
expression | For ActionExpression, ActionTaskDueDate, ActionTimedEvent, or variable, specifies a workflow expression that is meaningful within the context of the parent element. For ActionTaskAssignRole, ActionTaskAssignUser, or addressee, specifies a flag (true or false) that defines whether or not an associated value is represented as a workflow expression. | <expression> XPath(&quot; /order/text()&quot;) </expression>
false | Actions associated with a Decision node's false branch. You can define zero or more occurrences of the following subelement: %action-types. | <false> <ActionWorkflowAbort> <notes> This is a note. </notes> </ActionWorkflowAbort></false>
falsenexts | String specifying the next node associated with a Decision node's false branch. You can define zero or more occurrences of the following subelement: next. | <falsenexts> 963410128518 </falsenexts>
id | Unique ID that is meaningful within the context of the parent element. | <id>3</id>
idexpression | Expression used for identifying the workflow template definition. | <idexpression> &quot;Order&quot; +&quot;&quot; +:OrderNumber </idexpression>
in | Flag (true or false) specifying whether or not a variable, defined by a callable Start node, is an input parameter. | <in>true</in>
inmandatory | Flag (true or false) specifying whether or not an input variable, defined by a callable Start node, is a mandatory input parameter. | <inmandatory> true </inmandatory>
input-expression | Workflow expression that identifies the XML document for which an XSL transformation will take place. |
instanceid | Workflow instance ID that defines the target of the XML event defined by the ActionPostXMLEvent action. | <instanceid> 10 </instanceid>
instance-variable | Instance variable (name of the variable containing the Java object or EJB) on which WebLogic Process Integrator should invoke the business operation defined by the ActionBusinessOperation action. | <instance-variable> PobeanHandle </instance-variable>
instance-variable-type | Instance variable type of the instance variable defined by the instance-variable element. | <instance-variable-type> session </instance-variable-type>
iviewx | X-coordinate of a Studio interface view shape. | <iviewx>150</iviewx>
iviewy | Y-coordinate of a Studio interface view shape. | <iviewx>150</iviewx>
jmstype | JMS destination type. |
Join | Join node. You must define the following subelements: %node and | See Template Definition DTD Example.
key | Workflow expression that evaluates to a key at runtime. The system evaluates the workflow expression against the root element of an incoming XML document (of the specified type) to yield a key value that uniquely identifies that document instance. | <key> $orderid </key>
manual | Flag (true or false) specifying whether or not the Start node is manually startable. | <manual> true </manual>
markeddone | Actions associated with the task's Marked Done event. You can define zero or more occurrences of the following subelement: %action-types. | <markeddone> <ActionWorkflowSetComment> <notes> This is a note. </notes> <comment> &quot;Order Cancelled&quot; </comment> </ActionWorkflowSetComment>
message | E-mail message text to be sent as defined by the ActionSendEMail action. This value can be a valid workflow expression or literal string (in double quotes) that is evaluated at runtime. | <message> The order has been processed. </message>
message-properties | Message properties. You can define one or more occurrences of the following subelement: property. |
modifiable | Permission flag (true or false) specifying whether or not the task properties can be modified at run time, using the methods described in Setting Task Properties. | <modifiable> true </modifiable>
name | Unique string specifying the element name that is meaningful within the context of the parent element. | <name> Order Processing </name>
next | String specifying the next node to activate. | <next> 963410128518 </next>
nexts | A list containing zero or more next actions. You can define zero or more occurrences of the following subelement: next. | <nexts> <next> 963410128518 </next> </nexts>
nodes | Nodes defined for the workflow template definition. You can define zero or more occurrences of the following subelements: Decision Done Event Join Start Task | See Template Definition DTD Example.
notes | User-defined notes. | <notes> This workflow is used for order processing. </notes>
orderkey | Order key, used for ordered messaging, as described in Establishing JMS Connections. |
orgexpression | Workflow expression that specifies the organization associated with the workflow that you are attempting to start, using the ActionWorkflowStart action. |
out | Flag (true or false) specifying whether or not a variable, defined by a callable Start node, is an output parameter. | <out>false</out>
output-variable | Variable to which the result of the XSL transformation is stored. |
parameters | Initial parameter values to be set using an explicitly defined variable in the calling workflow. You can define zero or more occurrences of the following subelement: parm. | <parameters> <parm> <name> CustomerId </name> <value> $CustomerId </value> </parm> </parameters>
parm | Parameter definition. For an ActionBusinessOperation action, this element can be any character string. For ActionWorkflowStart action, you can define zero or more of the following subelement pairs: name value | <parm> :ItemNumber </parm>
parms | Parameter list, if required. You must specify zero or more occurrences of the following subelement: parm. | <parms> <parm> :ItemNumber </parm> <parm> :ItemQuantity </parm> <parm> :CustomerState </parm> </parms>
plugin | Plug-in entry. One element appears for each plug-in referenced by a template definition, and each plug-in that defines its own template definition property. Optionally, you can define the following subelement: plugin-data. You define the following attributes: name: Plug-in name. referenced: Flag (true or false) specifying whether or not the template definition uses the plug-in. major-version: Major version of plug-in software. minor-version: Minor version of plug-in software. vendor: Vendor name. url: URL (defaults to an empty string). For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration. | <plugin name="com.bea.wlpi.SamplePlugin" referenced="true" major-version="1" minor-version="0"> </plugin>
plugin-data | Plug-in data consisting of any combination of elements and text. You must define the following attributes: name: Name of the plug-in. This attribute is required. ID: Plug-in provided unique ID for the associated value object. This attribute is required. For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration. | <plugin-data name="com.bea.wlpi.SamplePlugin" ID="2"> <statusvariable> OrderStatus </statusvariable> <totalpricevariable> OrderTotalPrice </totalpricevariable> </plugin-data>
plugins | Plug-in definition, if plug-in is provided. You can define zero or more occurrences of the following subelements: plugin. For more information about programming plug-ins, see Programming BPM Plug-Ins for WebLogic Integration. | <plugins> <plugin name="com.bea.wlpi.SamplePlugin" referenced="true" major-version="1" minor-version="0"> </plugin> </plugins>
priority | Task priority. Possible values include: 0 (low), 1 (medium), and 2 (high). | <priority> 1 </priority>
program | Fully-qualified path to an executable program. | <program> MyProgram </program>
property | Message property. You must define the following subelements: name value |
queue | JMS queue to which an XML document is sent or retrieved. You must define the expression attribute to specify whether or not the value specified is an expression. This attribute defaults to false. | <queue> Queue1 </queue>
reassignment | Permission flag (true or false) specifying whether or not a task can be reassigned to another participant, using the methods described in Assigning a Task. | <reassignment> true </reassignment>
recoverable | Flag specifying whether or not you would like to recover all of the actions lost in the event of system failure. |
refvariable | Variable to which the workflow ID is saved when the workflow is started by a ActionWorkflowStart action. This variable can be used in expressions from within the calling workflow to retrieve variables. For example, NewWF.Name retrieves the value of the Name variable. | <refvariable> Name </refvariable>
replyto | Reply-to address |
reschedamount | Numeric value. This value specifies the number of reschedunits units from the dateexpression at which a time-triggered Start node is rescheduled. | <reschedamount> 30 </reschedamount>
reschedunits | Units used to express the reschedule time for a time-triggered workflow. Possible values include: 0: Milliseconds 1: Seconds 2: Minutes 3: Hours 4: Days 5: Weeks 6: Months 7: Business hours 8: Business days | <reschedunits> 0 </reschedunits>
result | Result. For an ActionBusinessOperation action, this element can be any character string. For an ActionWorkflowStart action, you must define the following subelements: name value | <result> PobeanHandle </result>
result-type | Type of result-type variable. | <result-type> Session </result-type>
results | Results. You can define zero or more occurrences of the following subelement: result. | <results> <result> PobeanHandle </result> </results>
role | For ActionTaskAssignRole, specifies an existing role or a workflow expression that evaluates to an existing role. If a workflow expression, the expression flag must be set to true. For ActionTaskAssignUser, specifies a flag (true or false) that indicates whether the user element specifies a user (false) or role (true). | <role> &quot;Role1&quot; </role>
rollback-actions | Actions performed when a transaction is rolled back. You can define zero or more occurrences of the following subelement: %rollback-action-types | <rollback-actions> <ActionTaskDone> <notes> This is a note. </notes> <target> 963511775400 </target> </ActionTaskDone> </rollback-actions>
root | Root element of an XML document that triggers the associated event. | <root>order</root>
routecondition | Route condition. You must define the following subelements: to type condition | <routecondition> <to>Role1</to> <type> userinrole </type> <condition> a+b </condition> </routecondition>
routeconditions | Route conditions. You can define zero or more occurrences of the following subelement: routecondition. | <routeconditions> <routecondition> <to>Role1</to> <type> userinrole </type> <condition> a+b </condition> </routecondition> </routeconditions>
scheduletime | Numeric value. This value specifies the number of scheduleunits units from the current time, that define the amount of time that must elapse before a time-triggered event (defined by the ActionTimedEvent action) is rescheduled. | <scheduletime> 5 </scheduletime>
scheduleunits | Units used to express the reschedule time. Possible values include: 0: Milliseconds 1: Seconds 2: Minutes 3: Hours 4: Days 5: Weeks 6: Months 7: Business hours 8: Business days | <scheduleunits> 0 </scheduleunits>
subject | Subject line for the e-mail message to be sent, as defined by the ActionSendEMail action. This value can be a valid workflow expression or literal string (in double quotes) that is evaluated at runtime. | <subject> Urgent </subject>
Start | Start node. For manually startable workflows, you must define the following subelements: %node description manual nexts actions variables iviewx (zero or one) iviewy (zero or one) For callable workflows, you must define the following subelements: %node description called nexts actions variables iviewx (zero or one) iviewy (zero or one) | See Template Definition DTD Example.
Start (cont) | For time-triggered workflows, you must define the following subelements: %node description timed dateexpression reschedamount reschedunits recoverable (zero or one) calendarname startorg nexts actions variables iviewx (zero or one) iviewy (zero or one) For event-triggered workflows, you must define the following subelements: %node description event root key condition startorg nexts actions variables |
Start (cont) | For plug-in-triggered workflows, you must define the following subelements: %node description plugin-data startorg nexts actions variables |
startorg | Organization associated with the Start node. | <startorg> &quot;ORG1&quot; </startorg>
stopwhentaskdone | Flag specifying whether to stop execution (and rescheduling) when the task (true) or workflow (false) completes. | <stopwhentaskdone> true </stopwhentaskdone>
target | Unique numerical value that identifies the element upon which you are operating, and that is meaningful within the context of the parent element. | <target> 963511923442 </target>
Task | Task node. You must define the following subelements: %node name priority donewithoutdoit doitifdone unmarkdone modifiable reassignment nexts actions | See Template Definition DTD Example.
template-entry | Target of an addressed JMS message. |
template-name | Workflow template name. | <template-name> ShipBill </template-name>
templateid | Template ID of the workflow to start, using the ActionWorkflowStart action. | <templateId> 3 </templateId>
time-to-live | Time-to-live value. | <time-to-live> 0 </time-to-live>
timed | Flag (true or false) specifying whether or not the Start node is time-triggered. | <timed> true </timed>
to | E-mail address(es) of the primary receipient(s) to be sent an e-mail message, as defined by the ActionSendEMail action. You can define zero or more occurrences of the following subelement: addressee | <to> <addressee> <name> joe@work </name> . <expression> false </expression> <type> address </type> </addressee> </to>
topic | JMS topic to which an XML document is sent or retrieved. You must define the expression attribute to specify whether or not the value specified is an expression. This attribute defaults to false. | <topic> Topic1 </topic
transaction | Boolean flag specifying whether or not the workflow can be part of a transaction. | <transaction> false </transaction>
transform-document | XSLT document used to transform input-expression |
transform-source | Flag that indicates whether transform-document is obtained from a workflow expression (E) or from the path to a XML repository file (R). | <transform-source> E </transform-source
true | Actions associated with a Decision node's true branch. You can define zero or more occurrences of the following subelement: %action-types. | <true> <ActionWorkflowAbort> <notes> This is a note. </notes> </ActionWorkflowAbort></true>
truenexts | String specifying the next node associated with a Decision node's true branch. You can define zero or more occurrences of the following subelement: next. | <truenexts> 963410128518 </truenexts>
type | For a variable, specifies one of the following variable types: boolean, date, double, entity (Entity EJB), integer, object, session (Session EJB), string, or xml. For a routecondition, specifies the type of the addressee (user, userinrole, or role) specified for the to element. For an addressee, specifies the type of the addressee (address, user, or role) specified for the name element. | <type>string</type>
unmarkdone | Permission flag (true or false) specifying whether or not the task can be executed once it has been marked done, using the methods described in Marking a Task as Complete or Incomplete. | <unmarkdone> true </unmarkdone>
user | User or user in role. This value can specify an existing user or role, or a workflow expression that evaluates to the user or role to which the task is assigned by the ActionTaskAssignUser action. If it is a workflow expression, the associated expression flag must be set to true. | <user>true</user>
usetimeexpression | Flag specifying whether to use the specified expression (true) or executiontime (false) to trigger an ActionTimedEvent action, | <usetimeexpression> true </usetimeexpression>
value | Parameter value that is meaningful within the context of the parent element. | <value> 5 </value>
variable | Variable defined for the workflow template definition. For a Workflow, you must define the following subelements: name notes type or plugin-data xmltype inmandatory in out For a Start node or ActionSendXMLToClient action, you must define the following subelements: name expression For an ActionExpression action, you must define the following subelements: name expression | <variable> <name> TotalPrice </name> <notes> This is a note. </notes> <type> double </type> <xmltype> </xmltype> <inmandatory> false </inmandatory> <in>false</in> <out>false</out> </variable>
variables | Variables defined for the workflow template definition. You can define zero or more occurrences of the following subelement: variable. | <variables> <variable> <name> TotalPrice </name> <notes> This is a note. </notes> <type> double </type> <xmltype> </xmltype> <inmandatory> false </inmandatory> <in>false</in> <out>false</out> </variable> <variables>
Workflow | Root element. You must define the following subelements: name effective changedby changeddate notes idexpression active audit-enabled plugins (zero or one) nodes variables error-handlers (zero or one) You must define the following attributes: major-version: Major version of software. Defaults to 1. minor-version: Minor version of software. Defaults to 0. build-number: Build number of software. Defaults to 0. | See Template Definition DTD Example.
x | X-coordinate of a Studio shape. | <x>20</x>
xml | XML document structure consisting of any combination of elements and text. | <xml> <order> &quot;new&quot; </order> </xml>
xmltype | XML document type, if variable type is set to xml. |
xsl-parameters | Parameters used for XML transformation. You must define one or more xsl-parameter subelements. |
xsl-parameter | Parameter used for XML transformation. You must define the following subelements: name expression |
y | Y-coordinate of a Studio shape. | <y>40</y>

Entity Descriptions

The following table describes the Template Definition entities.

Table A-19 Template Definition DTD Entities

Entity

Description

%action-types

Defines all action types, including the %std-action-typesand the following types:

- ActionInvokeErrorHandler

- ActionSetErrorHandler

%commit-action-types

Commit transaction action types, including the %std-action-typesand the following types:

- ActionExitErrorHandler

- ActionSetErrorHandler

%node

Node characteristics, including the following:

- id

- x

- y

- notes

%rollback-action-types

Rollback transaction action types, including the following:

- ActionAuditEntry

- ActionBusinessOperation

- ActionCallProgram

- ActionCondition

- ActionExitErrorHandler

- ActionExpression

- ActionNoOp

- ActionPlugin

- ActionPostXMLEvent

- ActionSendEMail

- ActionSendXMLToClient

%std-action-types

Standard action types, including the following:

- ActionAuditEntry

- ActionBusinessOperation

- ActionCallProgram

- ActionCancelEvent

- ActionCondition

- ActionExpression

- ActionNoOp

- ActionPlugin

- ActionPostXMLEvent

- ActionSendEMail

- ActionSendXMLToClient

- ActionTaskAssignRole

- ActionTaskAssignRoutingTable

- ActionTaskAssignUser

- ActionTaskDoit

- ActionTaskDone

- ActionTaskDueDate

- ActionTaskSetComment

- ActionTaskSetPriority

- ActionTaskUnassign

- ActionTaskUndo

- ActionTimedEvent

- ActionWorkflowAbort

- ActionWorkflowDone

- ActionWorkflowSetComment

- ActionWorkflowStart

- ActionXSLTransform

Template Definition DTD Example

The following example consists of excerpts from the Order Processing template definition that is provided in the examples directory. This example illustrates a valid application of the Template Definition DTD.

>     <?xml version="1.0" encoding="UTF-8"?>
>     <Workflow major-version="1" minor-version="2" build-number="0">
>       <name>Order Processing</name>
>       <effective>200007120000</effective>
>       <changedby>joe</changedby>
>       <changeddate>20011281424</changeddate>
>       <notes>This is a note.</notes>
>       <idexpression>&quot;Order&quot;+&quot; &quot;+:OrderNumber</idexpression>
>       <active>true</active>
>       <audit-enabled>false</audit-enabled>
>       <nodes>
>     	.
>     	.
>     	.
>       </nodes>
>       <variables>
>     	.
>     	.
>     	.
>       </variables>
>       <error-handlers>
>     	.
>     	.
>     	.
>       </error-handlers>
>     </Workflow>

The following sections provide detailed examples of each node type: Decision, Done, Event, Join, Start, and Task. For additional examples of each element, see Element Descriptions.

Decision Node Example

The following excerpt provides an example of a Decision node.

>         Decision>
>           <id>963410131712</id>
>           <x>100</x>
>           <y>140</y>
>           <notes></notes>
>           <condition>:Confirm=&quot;yes&quot;</condition>
>           <truenexts>
>             <next>963410119665</next>
>           </truenexts>
>           <falsenexts>
>           </falsenexts>
>           <actions>
>             <false>
>               <ActionPostXMLEvent>
>                 <notes></notes>
>                 <xml>
>                   <order>
>                     <status>&quot;cancelled&quot;</status>
>                     <ordernumber>:OrderNumber</ordernumber>
>                   </order>
>                 </xml>
>               </ActionPostXMLEvent>
>             </false>
>             <true>
>             </true>
>           </actions>
>         </Decision>

Done Node Example

The following excerpt provides an example of a Done node.

>         <Done>
>           <id>3</id>
>           <x>140</x>
>           <y>490</y>
>           <notes></notes>
>           <actions>
>           </actions>
>         </Done>

Event Node Example

The following excerpt provides an example of an Event node.

>         <Event>
>           <id>991155339988</id>
>           <x>370</x>
>           <y>10</y>
>           <notes></notes>
>           <iviewx>290</iviewx>
>           <iviewy>0</iviewy>
>           <description>Watch for Cancellation</description>
>           <root>cancelledorder</root>
>           <key>$OrderID</key>
>           <condition></condition>
>           <nexts>
>             <next>3</next>
>           </nexts>
>           <actions>
>           </actions>
>           <variables>
>           </variables>
>         </Event>

Join Node Example

The following excerpt provides an example of a Join node.

>         <Join>
>           <id>963511805733</id>
>           <x>110</x>
>           <y>230</y>
>           <notes></notes>
>           <and>true</and>
>           <nexts>
>             <next>963511923442</next>
>           </nexts>
>         </Join>

Start Node Example

The following excerpt provides an example of a Start node.

>     <Start>
>           <id>1</id>
>           <x>20</x>
>           <y>40</y>
>           <notes></notes>
>           <iviewx>150</iviewx>
>           <iviewy>50</iviewy>
>           <description>Start</description>
>           <called>true</called>
>           <nexts>
>             <next>2</next>
>             <next>963410125634</next>
>           </nexts>
>           <actions>
>           </actions>
>           <variables>
>             <variable>
>               <name>CustomerName</name>
>               <expression>XPath(&quot;/order/customer/name/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>CustomerId</name>
>               <expression>XPath(&quot;/order/customer/id/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>orderstatus</name>
>               <expression>XPath(&quot;/order/status/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>ordernumber</name>
>               <expression>XPath(&quot;/order/number/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>CustomerMail</name>
>               <expression>XPath(&quot;/order/customer/email/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>ItemName</name>
>               <expression>XPath(&quot;/order/item/name/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>ItemNumber</name>
>               <expression>XPath(&quot;/order/item/id/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>ItemQuantity</name>
>               <expression>XPath(&quot;/order/item/quantity/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>ItemPrice</name>
>               <expression>XPath(&quot;/order/item/price/text()&quot;)</expression>
>             </variable>
>             <variable>
>               <name>CustomerState</name>
>               <expression>XPath(&quot;/order/customer/state/text()&quot;)</expression>
>             </variable>
>           </variables>
>         </Start>

Task Node Example

The following excerpt provides an example of a Task node.

>         <Task>
>           <id>2</id>
>           <x>100</x>
>           <y>20</y>
>           <notes></notes>
>           <name>Confirm Order</name>
>           <priority>1</priority>
>           <donewithoutdoit>true</donewithoutdoit>
>           <doitifdone>true</doitifdone>
>           <unmarkdone>true</unmarkdone>
>           <modifiable>true</modifiable>
>           <reassignment>true</reassignment>
>           <nexts>
>             <next>963410131712</next>
>           </nexts>
>           <actions>
>             <created>
>             </created>
>             <activated>
>               <ActionTaskAssignUser>
>                 <notes></notes>
>                 <target>2</target>
>                 <user>joe</user>
>                 <expression>false</expression>
>                 <role>false</role>
>               </ActionTaskAssignUser>
>             </activated>
>             <executed>
>               <ActionSendXMLToClient>
>                 <id>959395846210</id>
>                 <notes></notes>
>                 <xml>
>                   <message-box title="&quot;Order Confirmation&quot;"
>                   style="&quot;question&quot;" options="&quot;yes_no&quot;">
>                   &quot;Do you Confirm this order?&quot;
>                   <actionid>&quot;959395846210&quot;</actionid>
>                   </message-box>
>                 </xml>
>                 <variables>
>                   <variable>
>                     <name>Confirm</name>
>                     <expression>XPath(&quot;/message-box/attribute::option&quot;)
>                     </expression>
>                   </variable>
>                 </variables>
>                 <actions>
>                   <ActionTaskDone>
>                     <notes></notes>
>                     <target>2</target>
>                   </ActionTaskDone>
>                 </actions>
>               </ActionSendXMLToClient>
>             </executed>
>             <markeddone>
>             </markeddone>
>           </actions>
>         </Task>

Workload Request DTD

The Workload Request DTD describes the format of the XML document that is used to generate runtime workload statistics. (The Workload Response DTD describes the format of the returned statistics report.) For information about the method used to query runtime workloads, see Querying the Run-Time Workload.

The following sections describe the Workload Request DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Workload Request DTD hierarchy.

Figure A-17 Workload Request DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Workload Request DTD, WorkloadReq.dtd.

>     <!ELEMENT workloadrequest (org, template
>                                | (template, templatedefinition)
>                                | (template, templatedefinition, task),
>                                pending, inactive, done, overdue,
>                                total, include, group)>
>     <!ELEMENT include (#PCDATA, user* | role*)>
>     <!ELEMENT org (#PCDATA)>
>     <!ELEMENT template (#PCDATA)>
>     <!ELEMENT templatedefinition (#PCDATA)>
>     <!ELEMENT task (#PCDATA)>
>     <!ELEMENT pending (#PCDATA)>
>     <!ELEMENT inactive (#PCDATA)>
>     <!ELEMENT done (#PCDATA)>
>     <!ELEMENT overdue (#PCDATA)>
>     <!ELEMENT total (#PCDATA)>
>     <!ELEMENT user (#PCDATA)>
>     <!ELEMENT role (#PCDATA)>
>     <!ELEMENT group (#PCDATA)>

Element Descriptions

The following table describes the elements of the Workload Request DTD.

Table A-20 Workload Request DTD Elements

Element | Description
--- | ---
done | Boolean flag specifying whether or not to include workflows marked as complete.
group | Boolean flag specifying whether or not to group report and display totals only.
inactive | Boolean flag specifying whether or not to include workflows that are inactive.
include | List of users and/or roles to include in the report. You can define the following subelements: user (zero or more) role (zero or mroe)
org | Organization for which the workload report is being generated.
overdue | Boolean flag specifying whether or not to include workflows that are overdue.
pending | Boolean flag specifying whether or not to include workflows that are pending.
role | Name of role to include in the report.
task | ID of the task for which the workload report is being generated.
template | ID of the template for which the workload report is being generated.
templatedefinition | ID of the template definition for which the workload report is being generated.
total | Boolean flag specifying whether or not to include all tasks, regardless of task state.
user | Name of user to include in the report.
workloadrequest | Root element. You must define the following subelements: org template | (template, templatedefinition) | (template, templatedefinition, task pending inactive done overdue total include group

Workload Response DTD

The Workload Response DTD describes the format of the XML document returned when querying runtime workloads. (The Workload Request DTD describes the format of the XML document used to request the query.) For information about querying the runtime workload, see Querying the Run-Time Workload.

The following sections describe the Workload Response DTD, including:

- Hierarchy Diagram

- DTD Format

- Element Descriptions

Hierarchy Diagram

The following diagram illustrates the Workload Response DTD hierarchy.

Figure A-18 Workload Response DTD Hierarchy Diagram

DTD Format

The following listing shows the format of the Workload Response DTD, WorkloadResp.dtd.

>     <!ELEMENT workload (item*)>
>     <!ELEMENT item (name, pending, inactive, done, overdue, total)>
>     <!ELEMENT name (#PCDATA)>
>     <!ELEMENT pending (#PCDATA)>
>     <!ELEMENT inactive (#PCDATA)>
>     <!ELEMENT done (#PCDATA)>
>     <!ELEMENT overdue (#PCDATA)>
>     <!ELEMENT total (#PCDATA)>

Element Descriptions

The following table describes the elements of the Workload Response DTD.

Table A-21 Workload Response DTD Elements

Element | Description
--- | ---
done | Number of tasks marked as complete for item.
inactive | Number of inactive tasks for item.
item | Item for which you are gathering the workload report. You must define the following subelements: name pending inactive done overdue total
name | Name of the item for which you are gathering the workload report.
overdue | Number of overdue tasks for item.
pending | Number of pending tasks for item.
total | Total number of tasks for item.
workload | Root element. You must define zero or more occurrences of the following subelement: item