Hi, I am working with a customer that has the following requirement:
We create a (business) activity request. The activity request has to undergo several checks which are performed in parallel and are independent. We want to be able to add new checks without having to release a new version of all our existing code or upgrade existing contracts.
My question is what would be the best way to achieve this? Some ideas I have are:
- Compile the activity definition into its own dar file, and each check into its own dar file, then have a parent dar that references the activity and all the checks. When a new check is added, release the new check dar plus the parent dar, leaving the activity and existing check packages unchanged.
- Use the new Interfaces capability to define a
ICheck interface and then somehow dynamically load the templates that implement it.
Or maybe there is a better approach altogether? Thanks!
From what I can read with regards to your requirements I’d say that the former approach should be good enough and it’s probably what I would recommend at this point: decouple data from behavior and evolve the latter whilst the former doesn’t change. This allows you to limit the scope of upgrading to behavior templates and leave data templates unchanged. One problem that you would still have is that of interacting with these behavior templates from off-ledger applications. At the very least, you would need to upgrade the package ID you are referring to, as well as evolving your off-ledger application to match the new and/or changes choices.
Interfaces will definitely represent a step forward in supporting the evolution of applications. They would, in a way, take over the role of those “behavior templates” I described above. There are two features of interfaces that are coming soon that will make evolving applications easier:
- interface subscriptions: you can have an off-ledger application subscribe to events by interface, meaning that as long as a template conforms to a given interface (i.e. an interface instance for that template exists), you will be able to view those contracts without changing the off-ledger application itself
- retroactive interface instances: you can define the interface instance for a template after the template has been defined, thus allowing you to evolve templates and have them conform with an existing interface
Something that allows to dynamically upgrade choices to enable zero-downtime upgrades is under study and an important priority for the team but unfortunately I cannot give you a certain timeline for that right now.
Thank you for confirming @stefanobaghino-da and for a comprehensive reply. Will try option 1.