In NServiceBus documentation there is statement that sagas should not call out to web services:
Other than interacting with its own internal state, a saga should not access a database, call out to web services, or access other resources - neither directly nor indirectly by having such dependencies injected into it.
Since there is no explanation on why not to do that I would like to ask community to help me with this one.
I understand why I cannot query database: state might have changed between issuing event and its processing. The part which I don't understand is about web services.
Why is it bad practice to POST to let's say Shipping web service with command to ShipOrder with given ID?
It's usually better to raise this kind of questions with the Particular Software team itself on https://discuss.particular.net/ or via regular support. The reason is that these questions are rather open and tend to create a thread of replies.
Since I am working for Particular Software, let's continue it here. You can always copy the question/thread.
The main reason is possible contention and consistency of saga state. Depending on persister, saga state is retrieved and persisted with either pessimistic or optimistic locking. Either way, if the transaction takes too long, it's possible another message will come in that correlates to the same saga instance. It might be processed on a different (concurrent) thread (or perhaps a scaled out endpoint) and it will either immediately fail (pessimistic locking) or while trying to persist the state (optimistic locking). The message will be retried.
This is normal behavior and not something that can be avoided. However the longer the lock is open, the more likely it is going to happen. The usual advice is to NEVER do anything else besides orchestration of a business process. So not even retrieving or storing your own business data. But with webservices you have no control over the webservice and it might take a connection timeout or ever longer before the message fails. Correlated messages will fail even faster and it's likely they'll eventually end up in the error queue.
Something that can be avoided by not doing anything else but orchestrate the business process and 'just' send messages. Keeping locks on data as short as possible.