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.
Monica J Martin wrote:
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
|