OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: wsbpel 3/31/2006: Section 9.2 RejectPO Examples


In Section 9.2, there was an addition during the Chapter 9 editing 
process to add a fault to the example shown below (SP:RejectPO). This 
change was likely made to be consistent with an earlier reference in the 
WSDL document for the fault RejectPO.

    ...Alternatively, if the request-response purchasing operation is
    used in the buyer's business process, the correlation sets are
    specified for the request and response messages of the invoke
    activity, respectively. The PO rejection from the seller is sent via
    a fault message.

    <invoke partnerLink="Seller" portType="SP:PurchasingPT"
        operation="SyncPurchase"
        inputVariable="sendPO"
        outputVariable="getResponse"> 
        <correlations>
             <correlation set="PurchaseOrder" initiate="yes"
                              pattern="request"/>
             <correlation set="Invoice" initiate="yes"
                              pattern="response"/>
        </correlations>  
        <catch faultName="SP:RejectPO" faultVariable="POReject"
                                          faultMessageType="smsg:POReject">
            ...
                 <!-- handle the fault -->
        </catch>
    </invoke>.....

I can understand that an external partner may define how this interface 
is exposed (and choose a fault). However, it is best advised to reserve 
faults to describing program malfunctions rather than business decisions 
that may carry other actions and obligations. I am uncertain we should 
be encouraging the use of faults, as this example does, to effect 
business decisions. Thanks.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]