Saga Deployment constraints

[janesser]

Use case:

• imagine several micro-services.
• their choreography is managed by a saga.

I have some struggle understand how saga evolution will be supported, or which constraints need to be respected in order to avoid trouble.

To me there are three critical phases:

Before the saga-changes:

• is some versioning in the saga-store? -- is there some facility similar to event-up-caster?

During the deployment of the saga-change?

• throughout a rolling deployment, for some time there are two versions available.
• is there some control of which one applies? -- will there apply randomly and alternating?

After the deployment:

• in terms of trace-ability, will the saga-version be visible?

On the bottom-line request is of course to elaborate regarding this matter on the reference guide. https://docs.axoniq.io/reference-guide/implementing-domain-logic/complex-business-transactions/implementing-saga

[janesser]

BUMP

in the meantime, i have been thinking that, once axon-server is becoming open-source, would it make sense to execute the saga on the axon-server. That has strong impact on scale-ability properties. Is there a custom usage like this somewhere?

[smcvb]

First off, I'd like to apologies that we've not responded to your issue earlier @janesser. We normally keep a close eye on every issue coming in, but it must have fallen through the cracks some how..

Then, for you question at hand, it definitely justifies some adjustments tot he 'Complex Business Tranasactions' page of the Reference Guide. We however typically refrain from answering questions on GitHub, as that's what the user group or otherwise StackOverflow (with the axon tag) are meant for.

However, in short:

• Saga versioning: The stored SagaEntry has a notion of revision, also leveraging the @Revision annotation, and yes you could leverage the upcaster mechanism to upcast your Sagas. However, for a Saga instance apposed to an Event, it is not important that you keep it's original format. I'd thus suggest to do a regular update on the Saga table instead, as a pragmatic solution. -Two Saga Versions: I find this question somewhat ambiguous, would you mind elaborating a little more?
• Saga Version Visibility: The revision is currently only present in the serialized format and is not exposed to your Saga instance upon message handling.
• Executing Sagas on Axon Server: We currently have no plans to make Axon Server run Java applications like a single Saga type. It however is commonplace/possible to have an application which only consists of the Saga implementations, which you'd run and connect to an Axon Server instance.