KIE Server allows to deploy multiple kjars, even the same project but different versions. And that is actually quite common to add new version of the project (kjar) next to already running. That in turn enforces to have unique container ids for each project.
Let's take an example - at the beginning we start with first project
Group id: org.jbpm
Artifact id: my-project
Version: 1.0
This project has single process inside and once built we deploy it with container id set to my-project.
Then we realized that the process needs an update (of whatever type) and thus we need to increase project version and again build and deploy it to KIE Server. So that gives us another project version
Group id: org.jbpm
Artifact id: my-project
Version: 2.0
Then we cannot deploy it with the same container id (my-project) so we need to change it to something else ... my-project2 (most likely ;))
So what's wrong with that? Well, first of all naming convention is starting to be affected by the versioning schema used, which might be good or bad, depending how it's used. But more important is that clients interacting with these projects must be aware of the versions all the time.
That in turn makes the client application to be bound to release cycle of the projects in particular to their new versions (and by that processes and other assets).
What can we do about it...?
The improvement that comes in version 7 allows to define aliases for containers (which is runtime representation of kjar). Alias can be added to as many containers as needed and by default (when not given) uses artifact id of the project.
Aliases are not constrained to the same group and artifact ids so project with different GA coordinates can use same alias. Then alias can be used all the time when interacting with KIE Server, the behavior differs depending on the operations performed as it might require some additional logic to figure out which is the actual container to be used. Let's examine these situations
Let's take an example - at the beginning we start with first project
Group id: org.jbpm
Artifact id: my-project
Version: 1.0
This project has single process inside and once built we deploy it with container id set to my-project.
Then we realized that the process needs an update (of whatever type) and thus we need to increase project version and again build and deploy it to KIE Server. So that gives us another project version
Group id: org.jbpm
Artifact id: my-project
Version: 2.0
Then we cannot deploy it with the same container id (my-project) so we need to change it to something else ... my-project2 (most likely ;))
So what's wrong with that? Well, first of all naming convention is starting to be affected by the versioning schema used, which might be good or bad, depending how it's used. But more important is that clients interacting with these projects must be aware of the versions all the time.
That in turn makes the client application to be bound to release cycle of the projects in particular to their new versions (and by that processes and other assets).
What can we do about it...?
The improvement that comes in version 7 allows to define aliases for containers (which is runtime representation of kjar). Alias can be added to as many containers as needed and by default (when not given) uses artifact id of the project.
Aliases are not constrained to the same group and artifact ids so project with different GA coordinates can use same alias. Then alias can be used all the time when interacting with KIE Server, the behavior differs depending on the operations performed as it might require some additional logic to figure out which is the actual container to be used. Let's examine these situations
Starting new process instance
As listed above unique container id disables clients to use single endpoint to be used to start process instances of given process id as they always need to provide container id which differs between versions. When alias is used instead client application can actually always use the same container alias (instead of container id) to always start latest version of the process.
To start process of latest version, KIE Server will get container alias and find all containers that declares that alias and then search for latest by comparing project versions - it's based on maven like version comparator though it only takes into account version and not group or artifact id.
So if we deploy the first project and then issue following request:
http://localhost:8230/kie-server/services/rest/server/containers/my-project/processes/evaluation/instances
where:
- my-project is container alias
- evaluation is process id
it will then start new instance from org.jbpm:my-project:1.0 project.
Next if we deploy the 2.0 version then issue exact same request (the URL) then the new instance will be started from org.jbpm:my-project:2.0 project.
That gives us options to continuously deploy new versions and ensure that client who relies on our processes will always use latest version of the processes available in the system. It works always on the live information so if you then remove version 2.0 from KIE Server and start another instance it will be back on org.jbpm:my-project:1.0 project as it's the latest one available.
Interacting with existing process instance
Interaction with existing process instances depends on the process instance id. To be able to perform any operation on process instance its id must be given. Then based on that information KIE Server will identify correct container id to be used.
Container id is needed to be able:
- unmarshal incoming data (like variables)
- find correct runtime manager
- marshal outgoing data
Both incoming and outgoing data might refer to project specific types (that can change between versions) and thus it's important that the right one is used.
Interacting with tasks
Similar to process instances, interaction with tasks is dependent on the task id. KIE Server will locate proper container by task id to be able to correctly deal with the requests. Container id is used for exact same operations as in process instance case (unmarshall and marshal data and find correct runtime manager).
Interacting with process definition image and forms
Interacting with process definition image and process forms will work same as start process - returns always the latest one when using container alias.
Below you can see this in action in the following screen cast. This screencast illustrates use with workbench integrated with KIE Server so as you can see when you press build and deploy you will be given all the details already filled in:
- container id is artifactId _ version
- alias is artifact id
Although you're in full control and can change both defaults to whatever you need.
And again, container aliases are set either explicitly (if given when creating containers) or implicitly (based on artifact id). Although that does not mean you have to use them. In some case container ids are good enough and they will still work the same way as they do now.
Hopefully this will bring another reason to move to KIE Server and start using its full potential :)
Hopefully this will bring another reason to move to KIE Server and start using its full potential :)
