Web Services and Enrolling in Distributed Transactions

igor.chladil · 2009-04-21

Hello,

I have the following scenario which I would like to orchestrate from outside of Navision (.NET) via native Navision Web Services:

1) I want to create Sales Order + Lines
2) I want to Post it

And mainly I want both steps 1) and 2) to share the same transaction. As Navision is based on WCF now, I have expected it to be able automatically to take care about the two phase commits and to be able to enroll in the external transactions.

In order to do that I have tried to use the following code in C# without success. It doesn't rollback if there is an error in e.g. posting in Navision.

using (System.Transactions.TransactionScope scope = new System.Transactions.TransactionScope())
{
  // SalesOrderService is native NAV WS proxy
  SalesOrderService.Create(ref SO);
  SalesOrderService.Post();
  scope.Complete();
}

The issue is that if both steps cannot run in a single transaction then for a lot of the scenarios I won't be able to use the simple "publish" method in Navision. Or at least some external logging would be necessary to cope with manual compensation of partially processed logical transactions making the development more complex.

Could anybody please suggest if Navision can enroll in the distributed transactions? If yes, then some working sample would be perfect

.

Thanks ahead,
Igor

kine · 2009-04-21

Each call to the WebService means separate transaction. You need to create function which will take the Order data (e.g. through XMLPort as parameter for the function), will process the data and will post them in one function.

igor.chladil · 2009-04-21

Thanks Kamil,

I know the various work arounds but all of these mean that I cannot easily use the out of the box options of the page publishing with potential for "page extension CU". If this is the case then it also complicates the usage of Navision as one of the parties in the orchestration scenarios [due to its isolation from the "other transactions"]. I have just hoped that this has been included but perhaps not documented in this release...

I also wondered this might have changed during rewrite to WCF as as far as I know the WCF supports enrollment in distributed transactions and so should the web services since some version.

Does anybody know if there is some plan to change it/support distributed transactions in the next NAV releases?

Thanks,
Igor

kine · 2009-04-21

I have no such an info. From beginning there was clearly stated that WebServices in NAV are not supporting "transactions" and each call is separate and there is no "status memory" or "context" between the calls and it must be done in other way.

I think that the main reason is to prevent performance problems which can lead from such solution, e.g. when the external application call the first function and crash after that. There is no easy way to "roll back" the transaction because NAV will not know about the application crash without leaving the connection somehow active. Right now the calls are based on HTTP protocol, where the request is send and response received.

We can only hope in something like that in some next version. Way around exists, it is not so "nice", but will work. Making the WS "transactional" can be too big job to do it in first version (but I just assume, may be I am wrong and WCF enable developers to do it easily).

We all are learning today how to use the WebServices.

freddy.dk · 2009-04-21

I don't think we are going to provide a mechanism that allows you to hold a transaction lock over multiple WS methods.
I am afraid this will lead to users experiencing more locking and stuff - and I am pretty sure that we would like to go the other way (offer the developer a way to COMMIT inside Web Services methods).

igor.chladil · 2009-04-22

Thanks Freddy,

I understand that the longer transactions means more locking and further potential issues, however the transaction if combined inside NAV should not be much shorter (there should be just some communication overhead in distributed transaction scenario).

Anyway I believe that both options can exist together - and having more options for me means I can choose the way I will handle the particular scenario:

1) Allowing COMMITs in the WS calls is perfect for implicit transactions.
I believe that the explicit nested COMMITs are "ignored" in the distributed transactions scenarios anyway; its just the rollbacks that are propagated back immediately.
2) Allowing enrollment may be a good option for more complex NAV automation scenarios. Such an option wouldn't be perhaps used in the majority of the scenarios, but we have a few customers that would be really interested in these options as they have multiple systems communicating a lot. It is always challenging to make distributed systems communicating nicely and having such an option would make this challenge easier.

I understand that providing more options may not be wanted by MS or on the priority list. Anyway thanks for the confirmation of how it works now, and we will see how it will work in the next NAV releases ...
Igor

Howdy, Stranger!

Quick Links

Categories

Web Services and Enrolling in Distributed Transactions

Comments