Next: , Previous: Invoking BPEL2oWFN, Up: Top



3 Warnings and Error Messages

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 <while> activity without an enclosing <sequence> activity. In this case, the second activity triggers this message.


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.


Footnotes

[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.