RE: [ebxml-bp] BTA-PreCondition/PostCondition in ebxmlbp-2.0.4-Example-os-PIP7C7For2.04-en.xml

["Moberg Dale" <dmoberg@axway.com>]

 

 

BTA-PreCondition/PostCondition in ebxmlbp-2.0.4-Example-os-PIP7C7For2.04-en.xml

This is the only example I could find for BTA-Pre/PostCondition:
 <PreCondition expression="true" expressionLanguage="DocumentEnvelope" />
<PostCondition expression="true" expressionLanguage="DocumentEnvelope" />

What's the meaning of this Pre/PostCondition?
Where is it defined?

 

Again, this example is actually intended to illustrate how a BPSS 1.* level process description can be converted into an ebBP 2.0 level description.

 

Because of differences in the specifications, the conversion is not perfect and usually can benefit from some touchups.

 

Here is what the 2.0 level description derives from (including a comment)

 

<BinaryCollaboration name="Notify Of Semiconductor Test Data" nameID="NotifyOfSemiconductorTestData_BC"

initiatingRoleID="FoundryOrTestServicesID" preCondition="true" postCondition="true">

            <Documentation>The PIP Start State is comprised of the following conditions: a. TPA Approved and Exist In Backend System b. Sending Partner Exist as Party and Valid c. Receiving Partner Exist as Party d. Business Document Exist In Backend System, Valid, Non-Repudiated and Authorized </Documentation>
            <Documentation>The PIP End States are comprised of the following conditions: a. Acknowledgment of Receipt Exist In Backend System, Valid and Non-Repudiated b. Receiving Partner Authorized ; PIP Failure State: a. NOT Successful b. Retry Count Exceeded</Documentation>
           

 

<!—stuff deleted à                                        

</BinaryCollaboration>

 

 

It looks to me that the original example was just using a placeholder. The Documentation does show that the author had some ideas of what constituted pre and post conditions. But the translation assumed “DocumentEnvelope” language but the value “true()” should be from XSLT …

 

Again, relating the conditionexpression values to testing/monitoring tasks is still undergoing development and at present we all can benefit from implementation and modeling experience so that we can develop a more useful standardization of these expression languages. (which are crucial to actually expressing the real logic behind business process transitions...)