BPEL2oWFN performs several analysis steps on the input BPEL process. These messages are displayed during parsing and postprocessing of the process, and can be classified as follows:
An example for a message is this:
CubeManagement.bpel:566 - [W00114] variable `waitResponse' used as `variable' in <from> might be uninitialized
The first line contains the filename of the input process CubeManagement.bpel and the line number 566 of the displayed issue. The line number might be imprecise; that is, it might deviate up or down a few lines. After the line number, the error code is displayed. W00114 stands for a warning with code 114. The detailed description of the messages can be suppressed with option -d0.
Further details can be taken from the table below.
Code | Type | Description
|
---|---|---|
2 | static analysis |
A WS-BPEL processor MUST reject any WSDL portType definition that includes
overloaded operation names.1
|
3 | static analysis |
If the value of exitOnStandardFault of a <scope> or <process>
is set to "yes" , then a fault handler that explicitly targets the WS-BPEL
standard faults MUST NOT be used in that scope.
|
6 | static analysis |
The <rethrow> activity MUST only be used within a faultHandler (i.e.
<catch> and <catchAll> elements).
|
5 | static analysis |
If the portType attribute is included for readability, in a <receive> ,
<reply> , <invoke> , <onEvent> or <onMessage>
element, the value of the portType attribute MUST match the portType
value implied by the combination of the specified partnerLink and the role
implicitly specified by the activity.
|
7 | static analysis |
The <compensateScope> activity MUST only be used from within a
faultHandler , another compensationHandler , or a
terminationHandler .
|
8 | static analysis |
The <compensate> activity MUST only be used from within a
faultHandler , another compensationHandler , or a
terminationHandler .
|
15 | static analysis |
To be instantiated, an executable business process MUST contain at least one
<receive> or <pick> activity annotated with a
createInstance="yes" attribute.
|
16 | static analysis |
A partnerLink MUST specify the myRole or the partnerRole ,
or both.
|
17 | static analysis |
The initializePartnerRole attribute MUST NOT be used on a partnerLink
that does not have a partner role.
|
18 | static analysis |
The name of a partnerLink MUST be unique among the names of all
partnerLinks defined within the same immediately enclosing scope.
|
23 | static analysis |
The name of a variable MUST be unique among the names of all variables defined
within the same immediately enclosing scope.
|
24 | static analysis |
Variable names are BPELVariableNames , that is, NCNames (as defined in
XML Schema specification) but in addition they MUST NOT contain the
. character.
|
25 | static analysis |
The messageType , type or element attributes are used to specify
the type of a variable. Exactly one of these attributes MUST be used.
|
32 | static analysis |
For <assign> , the <from> and <to> element MUST be one
of the specified variants.2
|
35 | static analysis |
In the from-spec of the partnerLink variant of <assign> the value
"myRole" for attribute endpointReference is only permitted when the
partnerLink specifies the attribute myRole .
|
36 | static analysis |
In the from-spec of the partnerLink variant of <assign> the value
"partnerRole" for attribute endpointReference is only permitted
when the partnerLink specifies the attribute partnerRole .
|
37 | static analysis |
In the to-spec of the partnerLink variant of <assign> only partnerLinks
are permitted which specify the attribute partnerRole .
|
44 | static analysis |
The name of a <correlationSet> MUST be unique among the names of all
<correlationSet> defined within the same immediately enclosing scope.
|
51 | static analysis |
The inputVariable attribute MUST NOT be used on an Invoke
activity that contains <toPart> elements.
|
52 | static analysis |
The outputVariable attribute MUST NOT be used on an Invoke
activity that contains <toPart> elements.
|
55 | static analysis |
For <receive> , if <fromPart> elements are used on a
<receive> activity then the variable attribute MUST NOT be used on the
same activity.
|
56 | static analysis |
A “start activity” is a <receive> or <pick> activity that is
annotated with a createInstance="yes" attribute. Activities other than
the following: start activities, <scope> , <flow> and
<sequence> MUST NOT be performed prior to or simultaneously with start
activities.
|
57 | static analysis |
If a process has multiple start activities with correlation sets then all such
activities MUST share at least one common correlationSet and all common
correlationSets defined on all the activities MUST have the value of the
initiate attribute be set to "join" .
|
59 | static analysis |
For <reply> , if <toPart> elements are used on a <reply>
activity then the variable attribute MUST NOT be used on the same
activity.
|
62 | static analysis |
If <pick> has a createInstance attribute with a value of
yes, the events in the <pick> MUST all be <onMessage>
events.
|
63 | static analysis |
The semantics of the <onMessage> event are identical to a
<receive> activity regarding the optional nature of the variable
attribute or <fromPart> elements, if <fromPart> elements on an
activity then the variable attribute MUST NOT be used on the same activity
(see SA00055).
|
64 | static analysis |
For <flow> , a declared link's name MUST be unique among all
<link> names defined within the same immediately enclosing
<flow> .
|
65 | static analysis |
The value of the linkName attribute of <source> or
<target> MUST be the name of a <link> declared in an enclosing
<flow> activity.
|
66 | static analysis |
Every link declared within a <flow> activity MUST have exactly one
activity within the <flow> as its source and exactly one activity within
the <flow> as its target.
|
67 | static analysis |
Two different links MUST NOT share the same source and target activities; that
is, at most one link may be used to connect two activities.
|
68 | static analysis |
An activity MAY declare itself to be the source of one or more links by
including one or more <source> elements. Each <source>
element MUST use a distinct link name.
|
69 | static analysis |
An activity MAY declare itself to be the target of one or more links by
including one or more <target> elements. Each <target> element
associated with a given activity MUST use a link name distinct from all other
<target> elements at that activity.
|
70 | static analysis |
A link MUST NOT cross the boundary of a repeatable construct or the
<compensationHandler> element. This means, a link used within a
repeatable construct (<while> , <repeatUntil> , <forEach> ,
<eventHandlers> ) or a <compensationHandler> MUST be declared in
a <flow> that is itself nested inside the repeatable construct or
<compensationHandler> .
|
71 | static analysis |
A link that crosses a <catch> , <catchAll> or
<terminationHandler> element boundary MUST be outbound only, that is,
it MUST have its source activity within the <faultHandlers> or
<terminationHandler> , and its target activity outside of the scope
associated with the handler.
|
72 | static analysis |
A <link> declared in a <flow> MUST NOT create a control cycle,
that is, the source activity must not have the target activity as a logically
preceding activity.3
|
73 | static analysis |
The expression for a join condition MUST be constructed using only Boolean
operators and the activity's incoming links' status values.
|
74 | static analysis |
The expressions in <startCounterValue> and <finalCounterValue>
MUST return a TII (meaning they contain at least one character) that can be
validated as a xsd:unsignedInt . Static analysis MAY be used to detect
this erroneous situation at design time when possible (for example, when the
expression is a constant).
|
75 | static analysis |
For the <forEach> activity, <branches> is an integer value
expression. Static analysis MAY be used to detect if the integer value is
larger than the number of directly enclosed activities of <forEach> at
design time when possible (for example, when the branches expression is a
constant).
|
76 | static analysis |
For <forEach> the enclosed scope MUST NOT declare a variable with the
same name as specified in the counterName attribute of
<forEach> .
|
77 | static analysis |
The value of the target attribute on a <compensateScope>
activity MUST refer to the name of an immediately enclosed scope of the
scope containing the FCT-handler with the <compensateScope>
activity. This includes immediately enclosed scopes of an event handler
(<onEvent> or <onAlarm> ) associated with the same scope .
|
78 | static analysis |
The target attribute of a <compensateScope> activity MUST refer
to a scope or an invoke activity with a fault handler or
compensation handler.
|
79 | static analysis |
The root scope inside a FCT-handler MUST not have a compensation
handler.
|
80 | static analysis |
There MUST be at least one <catch> or <catchAll> element within
a <faultHandlers> element.
|
81 | static analysis |
For the <catch> construct; to have a defined type associated with the
fault variable, the faultVariable attribute MUST only be used if either
the faultMessageType or faultElement attributes, but not both,
accompany it. The faultMessageType and faultElement attributes
MUST NOT be used unless accompanied by faultVariable attribute.
|
82 | static analysis |
The peer-scope dependency relation MUST NOT include cycles. In other words,
WS-BPEL forbids a process in which there are peer scopes S1 and S2
such that S1 has a peer-scope dependency on S2 and S2 has a peer-scope
dependency on S1.4
|
83 | static analysis |
An event handler MUST contain at least one <onEvent> or
<onAlarm> element.
|
84 | static analysis |
The partnerLink reference of <onEvent> MUST resolve to a partner
link declared in the process in the following order: the associated scope
first and then the ancestor scopes.
|
88 | static analysis |
For <onEvent> , the resolution order of the correlation set (s)
referenced by <correlation> MUST be first the associated scope and then
the ancestor scopes.
|
91 | static analysis |
A scope with the isolated attribute set to "yes" is called an
isolated scope. Isolated scopes MUST NOT contain other isolated scopes.
|
92 | static analysis |
Within a scope, the name of all named immediately enclosed scopes MUST be
unique.
|
93 | static analysis |
Identical <catch> constructs MUST NOT exist within a
<faultHandlers> element.
|
100 | notice |
Either a non-standard element5 was parsed
or a BPEL activity was considered as
misplaced. In the first case, a non-standard element was parsed when the
parser expected a BPEL standard activity. Then, a syntax error is
printed and the whole element is ignored. The parse error and this message
can usually be ignored, as non-standard elements would neither we translated
to a Petri net model nor are constrained by the WS-BPEL
specification.
In the second case, a syntactically correct BPEL
was skipped, because it was misplaced. As an example, consider two activities
embedded in a |
101 | notice |
The <partners> construct (only supported by BPEL4WS 1.1) is skipped due
to a syntax error.
|
102 | notice |
The <to> or <from> construct is skipped due to a syntax error.
|
103 | notice |
The <condition> construct is skipped due to a syntax error.
|
104 | critical |
When a syntax error occurs, BPEL2oWFN tries to recover and continues parsing the
input file after skipping the faulty or unknown element. Sometimes, however,
the skipping of activities yields to situations where a further analysis of the
BPEL process is impossible. In this case, the syntax of the process
has to be fixed or non-standard elements have to be removed or out-commented.
|
105 | notice |
When a syntax error occurs, BPEL2oWFN tries to recover and continues parsing the
input file after skipping the faulty or unknown element. If it is possible to
continue, the analysis results might be faulty. In this case, the syntax of the
process has to be fixed or non-standard elements have to be removed or
out-commented.
|
106 | warning |
CFG analysis detected two receiving activities (i.e., <receive> ,
<onEvent> , <onMessage> , synchronous <invoke> ) that might
be activated concurrently and share the same partner link, port type, operation,
and correlation set. When a message is sent to the process, these activities
are in conflict; that is, it is not defined which activity will receive an
inbound message. At runtime, the standard fault bpel:conflictingReceive
would be thrown.6
|
107 | warning |
A mandatory attribute of an activity was not defined. Especially for
communicating activities, the absence of partnerLink and
operation might hamper the subsequent analysis and Petri net generation.
|
108 | syntax |
An attribute was set to a value that violates the attribute's given type. Only
the types tBoolean , tInitiate , tRoles , and
tPattern are checked.
|
109 | warning |
A variable referenced in an activity was not defined before; that is, no
matching <variable> definition was found in a parent scope.
|
110 | warning |
A partner link referenced in an activity was not defined before; that is, no
matching <partnerLink> definition was found in the process.
|
111 | warning |
A correlation set referenced in an activity was not defined before; that is, no
matching <correlationSet> definition was found in a parent scope.
|
112 | notice |
The <literal> construct is skipped due to a syntax error.
|
113 | syntax |
A UTF-8 character was read in the input file. As BPEL2oWFN's scanner does not
support Unicode, all UTF-8 characters are ignored. This message is only
displayed when the first UTF-8 character is read.
|
114 | warning |
CFG analysis detected a read access to a variable that was not
initialized before. At runtime, the standard fault
bpel:uninitializedVariable would be thrown.7
|
115 | notice |
The process definition defines an abstract process profile, and thus allows
several “opaque” constructs. When processing and analyzing an abstract
process, BPEL2oWFN might report error messages that where designed for
executable processes, for example missing attributes. Static analysis errors
detected in an abstract process are reported as warnings.
|
116 | notice |
An <opaqueActivity> of an abstract process is modeled by an <empty> activity.
|
117 | notice |
When using the parameter small, the occurrence of join
failures is not modeled. Thus, any activity is treated as if the
attribute suppressJoinFailure is set to yes.8
|
118 | notice |
A user-defined transition condition is ignored and modeled as “n-out-of-n”
(true) instead.
|
119 | notice |
A user-defined transition condition is ignored and modeled as “1-out-of-n”
(XOR) instead.
|
120 | notice |
When using the parameter small, the FTC (fault, termination,
and compensation) handlers are not modeled.
|
121 | notice |
When using the parameter small, activities of the negative
control flow (<exit> , <throw> , <compensate> , and
<compensateScope> ) are replaced by an <empty> activity.
|
122 | notice |
A syntax error in the BPEL4Chor chorography file occurred.
|
123 | notice |
A syntax error in the WSDL input file occurred.
|
124 | notice |
An XML Schema element nested in a WSDL <types> element was ignored. This is
usually no problem, as WSDL <types> are not evaluated in subsequent analysis
or translation.
|
125 | notice |
A variable property element was ignored while parsing the input WSDL file.
|
126 | warning |
A WSDL <message> referenced in a WSDL <operation> was not found.
|
127 | warning |
A WSDL <portType> referenced in a WSDL <role> was not found.
|
128 | warning |
A WSDL <operation> referenced in a BPEL activity was not specified in the
input WSDL file.
|
129 | warning |
A WSDL <role> of a partnerLinkType referenced by a <partnerLink> was not
defined in the specified <partnerLinkType> in the input WSDL file.
|
130 | warning |
A WSDL <partnerLinkType> referenced by a <partnerLink> was not specified in
the input WSDL file.
|
131 | error |
An activity has neither a name or id attribute and thus can not be linked with a BPEL4Chor <messageLink> .
|
132 | error |
An activity has neither could not be linked with a BPEL4Chor <messageLink> using the activity's name or id attribute.
|
133 | notice |
An <extensionActivity> is replaced by an <opaqueActivity> (cf. notice 116).
|
134 | warning |
A BPEL4Chor <participantType> was defined twice.
|
135 | warning |
The <participantType> referenced by a BPEL4Chor <participant> was not found.
|
136 | error |
The value of a <forEach> 's attribute id or name does not reference a BPEL4Chor
<participant> or <participantSet> . Thus, the <forEach> activity is not grounded to the
BPEL4Chor topology.
|
137 | error |
In a BPEL4Chor topology, no XML namespace was defined for a <participant> . In a
WS-BPEL file, the attribute targetNamespace could not to be grounded to a
BPEL4Chor <participant> .
|
138 | notice |
In a BPEL4Chor topology, a partner link specified for an activity was not found. Instead,
the name of the specified id is used as a partner link.
|
[1] The descriptions for static analysis messages are taken from Appendix B of the WS-BPEL specification.
[2] The specification describes all allowed combinations of elements and attributes in from- and to-specifications.
[3] This fault can only be detected in mode mode cfg.
[4] This fault can only be detected in mode mode cfg.
[5] All elements that are not explicitly defined in the WS-BPEL specification (e.g., elements from other namespaces) are considered as “non-standard”.
[6] This fault can only be detected in mode mode cfg.
[7] This fault can only be detected in mode mode cfg.
[8] If the attribute suppressJoinFailure is not explicitly defined for an activity, the value is inherited by the parent activity.