If you have reservation process that includes a payment transaction involving processing a credit card by accessing another system using XML-RPC over HTTPS or looking up customer details on another system using HTTPS, and you want the process to be all within a single transaction so that if the process fails at some point the payment transaction on the other system rolls back etc, how can you guarantuee this?
Or do you just assume that the other systems support transactions propagated from you to them with the HTTPS protocol?
Any one has any thoughts?
Thanks
Peter
Dan Drillich
Ranch Hand
Joined: Jul 09, 2001
Posts: 1121
posted
0
Hi Peter,
I would go with your second choice - assumptions
Regards, Dan
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Ricardo Ferreira
Ranch Hand
Joined: Feb 13, 2006
Posts: 156
posted
0
Peter,
Normally, your scenario is very common for any web distributed application, and the most common approach is, let the subsystem manage the transaction to you, and provide only an code the signals the transaction.
For example, your application could call an web service to process a credit card shopping, and if the web service call return 102 code, means that the credit card processing has been failed. Your application based on this code should rollback any operations that could be done.
But, there is some cases the an transactions must be started by one application and propagated for others web services. To meet this requirement, you must use some SOA infrastrcture like ESB (Enterprise Service Bus) that take care of this transaction propagation.
The ESB service do this creating a common tunnel that every incomming and outcomming web services must pass by it. And an transaction could be remaining during some business service execution.
But honestly, at the most cases, the called web service takes care of the processing transaction and signals are shared among the business processes. SOA and ESB is a emerging industry technology that do not have many cases using this approach. But this story tends to change as Gartner has said a few months ago
We can theoretically assume that Transmaster supports WS-Transaction, but it seems that Perl-based Frequent Flyer system does not offer any transactional API.
JCA Adapters for both?
Andrew Zilahi
Ranch Hand
Joined: Oct 16, 2006
Posts: 47
posted
0
Perform only 1 payment at a time. FBN system records all aspects of the transaction less a flag (isPaid or something), then issues transmaster request. If transmaster call fails, error log is being generated and isPaid = false. What do you think?
I think in most cases XA transaction is not possible, especially when it invovles external sources or legacy system. Regarding WS-Transaction, I don't expect TransMaster provide it to FBN. So I will split the transaction to 3 parts. 1. Make an order, persit it to database. 2. call TransMaster 3. Get returned code from TransMaster, do post process, persist the code to the related order.
If step 1 fails, skip step 2 and 3. If step 2 fails, some internal process will redo it automatically or a alert will be sent with other manual process. If step 3 fails, redo step 2 and let customer service handle double charge and customer complaim.
0
