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: Re: [wsbpel] wsbpel 3/31/2006: Section 9.2 RejectPO Examples



> vanderRijn: You have a good point.  Any idea how the examples should 
> work?  Should we just remove all references to the SP:RejectPO fault, 
> and catching it?  This would leave our examples slightly non parallel, 
> but we could fix that by removing the one-way AsyncPurchaseReject as well.

mm1: At a minimum, I'd suggest we remove the fault. More syntactic savvy 
folk can propose other changes. Thanks.

>> 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.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your TCs 
>> in OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>




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