 We will talk about JBL's GPM. Welcome back. Thanks for coming for the invitation. And today I'll be talking about JBL, which is a process language for the workflow part of the JBL's JPM product. So JBL itself covers many process languages and JBL is one, and that's the one we'll focus on. But first, a little bit of introduction. You might have heard, actually it's a question. Who heard of workflow, business process management, and or orchestration before? A couple of them. Who's pretty skeptical about these technologies? A few honest guys. That's good. Now, because typically, and this is a typical developer audience, and with developers workflow and orchestration and BPM, they tend to be quite skeptical. Whereas managers, they see some graphical picture, software comes out of there. This is great, because we have all our difficult developers, so they like it very much instantly. Whereas for developers, it usually takes a lot more to convince them about this technology, and that's what I'm going to try to do here today. If you've seen these pictures about these heavyweight engines, these mobility engines that do BPM and workflow, you might have seen different solutions, and they don't look very much like each other. There is a lot of difference, a lot of fragmentation in that market. What I'm going to try and show you today, that whichever version of BPM workflow you take, it all boils down in the end to state machines. So the unification of all this is a simple state machine, and there is a number of features that they build on top of that. So first of all, what is a process language? We'll start from a business process. A business process is a description of how people and systems work together, typically done in terms of activities. They express the flow between the activities. Typical examples are insurance claims, expense notes, and that kind of things that are modeled as workflows. But very important, that's where we differ a little bit from the vision of competing products. We see that there are two different targets for BPM and workflow. On the one hand, we want to model things, we want to describe and analyze the problem. For instance, recently I was at a laboratory where they modeled how these samples were processed. And they had a whole description of how these plates with 96 samples could be split, merge, and how they were treated. But while they were describing that process, they were not even thinking about what kind of computer system do we want in the back, what kind of interface do we want, which steps do we want to see automated. So they were not thinking about a software implementation, they were just describing a problem domain. So that's where modeling is different from implementing a software system. And that's the second target. The second target of workflow BPM is executability, which means we want to have the same process that we used for modeling. We want to use it as a basis for our software implementation, for specifying the behavior of the computer system. And that's where there is a trade-off between these two, because if you have an analysis tool that allows you to draw your process very freely, like Visio, or maybe you've heard of Aris, the IESI. She have two. You can model your business processes, but you cannot execute them properly in that environment. You can draw them. And in the description in the drawing, you are completely free. So that's one kind of technology. The other end of the spectrum is a general-purpose language like Java, in which you are free to make everything executable, but you cannot have the graphical picture. And that's where JPL tries to make a bridge between the two. So there is a trade-off. The more you want the process language to be executable, the more technical details you have to enter, like transaction management, concurrency support, and what have you, in which your business analyst is not interested. On the other hand, when a business analyst draws a picture, it might not be executable. So there is a trade-off, but there is a common intersection, let's say. And that's what we want to... That's what we are actually offering in JPL process language, which is if you put some restrictions on how you model, then you can make your processes executable. But definitely the important thing is that we see a trade-off between these two worlds, and you cannot have free modeling and executable at the same time. And the typical approach, this is very, very important. I'm going to focus here on what can we make graphical and executable. That's what I'm going to try to show you today. But also be informed that a typical BPM approach, when you see something graphical, that's a different approach. That's just creating something graphically and trying to make it executable. But then you have to be aware that not always the business analyst will understand these pictures. A typical example is Deepa. Deepa is considered a BPM language, at least not in my opinion. It is a very good service orchestration language. Deepa actually allows you to script a new web service as a function of other web services. And this is something which doesn't really relate to the work that the business analyst is doing, and yet is promoted for that kind of solution. So then what is a process language? Here you can see a real example or an indication to what JTBL is all about. On the right you see the XML syntax embedded process language that describes the activities in your process in an XML format. On the left you see the process graphical picture, just a graph-based picture. Now you should really consider this as two independent or let's say no. These are both representations of the same process. So one is a diagram and it just shows you the structure. It doesn't show all the details. While in the XML you'll find the structure plus more details. And from the XML you can generate a picture. So why would you use a process language like JTBL? First of all to simplify your implementation of long-running processes. A lot of you will be hard-core developers so you know that the imperative programming language like Java or C is very good at expressing a sequence of instructions. But while you're executing that sequence of instructions you cannot have a wait state at least. So if you have an insurance claim for instance that might be multiple requests to the server. So the first time request comes in you start to do processing. You start to execute a sequence of instructions now you need to wait until some other person invokes a new request. You cannot just block the thread until that thing happens because if you reboot your server your thread is gone. So you cannot persist your call stack that's basically what comes down to it. Traditional programming language are not good at expressing long-running executions and they are not able to cope with wait states. So that's what you can get by using this process language approach because basically what you can do is the graphical process, the graph you can just store it in the database and then you have an execution point that keeps track of where you are in the graph. Now both of those can be saved in the database. So later on you can retrieve where you were in the execution of the database and continue from there on. So that kind of state management can now with a technology like JVM be extracted from the rest of your software so that you can focus on other things and just as a separate aspect model the wait states and the persistence. So the second reason why you would do that is to keep the overview and improve communications. So if you have to talk to your less technical people if you as a developer need to talk to less technical people or to other developers it might be handy in meeting to have a picture so that they can physically pinpoint this is the step I'm talking about. This is the transition. When this happens an email should be sent or whatever. So it's a nice instrument to improve the communication. Now in general when would you use a process language for any aspect in software development where you want a diagram a graphical representation of the process which represents some form of execution flow and which must be able to handle wait states. If those two conditions are met I'm pretty sure that JVDL will be a good solution to your problem and this can be very low level. It might be that you have a Java class that you think as a developer oh I see some kind of wait statement here that's prime model is graphically you can use JVDL for that. On the other hand if you want to talk to your business analyst about how your organization works and how the business processes in your organization works that meets the same criteria so you can also use JVDL on that level. So various levels but these three aspects meet me. If you have those three conditions then the JVDL process language is a good fit. On the other hand you also have history and statistics for free when you model it as a JVDL process and you execute it afterwards there is a dramatic login in there that keeps track of this time this activity was entered was presented with a task and later on you can see this user has entered these data items and submitted it so that the process moved on so there is auditability and traceability of the execution that you get from the entity. Now let's look at JVDL. It's a kind of product or actually it's a framework or let's say a set of building blocks in plain Java in which we implement various process languages one of them is JVDL that we covered today and basically the process virtual machine is one Java library that allows you to specify process graphs and execute them on a generic level but we have built this process virtual machine in such a way that we know that all the features that we find in process languages and workflow languages can be built on top of that and each process language has got its own environment its own type of process modes and its own features and functions that it wants to implement so for instance JVDL is a language which targets a clean integration with Java and it also has a focus on task management maintaining tasks for people creating tasks and allowing users to submit results for their tasks so that's a number of features that we add on top of the state machine technology which is in the process virtual machine the same for people people is another process language in a completely different environment now we're in a web services environment typically an enterprise service list and the people process language allows you to script the web service as a function of other services so it's another environment where you want to say process variables as six and else numbers whereas in JVDL you won't Java objects as process variables and then there is also a page rule language which is part of JVOS scene in which you specify your pages as nodes and the transitions are the navigation between the pages in your web application so we already have been able for these three languages to build them on the same core technology in the process virtual machine and we're now starting work on JVDL which is an understanding of the area for business process management and building it on top of the same this is pretty unique because in the Java landscape you have no other BPM or workflow engine that is able to support more than one language and what you see in the market is that there is no convergence between all these different languages instead they diverge you see more differences between the process languages each week or each month so there is no convergence towards a single language and we are the first ones to adopt a multi process language strategy for them actually there is only one other system or one other technology that has a similar kind of approach with multiple languages but you probably don't want to hear about it because it's Microsoft's workflow foundation so this is your only option so here you can see the scope of JVDL it's the process virtual machine implementation plus the setup process languages on top now if you as a developer have the use case for workflow or BPM you have a certain environment either you want to do it in a Java environment or in a web services environment so you know what kind of language you are looking for so you will be looking for the specific JVDL or deep process language solutions built on JVDL or as part of JVDL but now you know that they are actually built on top of the same core technology which is especially good if you consider the future meaning that whenever workflow and BPM technology becomes you agree with this mind chat amongst the developers and you will be using it a lot in different situations are you going to use multiple agents in your development one for each language so the nice thing about JVM is that you can combine those and use just one engine for the different languages so now let's take it from a different perspective and look at a first example and especially I want to concentrate on developers audience in which I want to give them an indication of when to use plain Java development and when to use process technology so we are going to start with a very simple process just we are going to model how a door works should be pretty straightforward and we are going to do this first in Java implementation so that you know what we are talking about and then we are going to see the JVDL process implementation so there are four door states the door can either be locked, closed, open or open and locked in which case you cannot close it directly so first you have to unlock it to close it so and then you have a number of transitions between those so there are four different operations you can unlock, close and open this door now let's look at the Java implementation so you could model it as a class in which there is one member field which represents the state called the state member field and it's always one of the four constants that you can see defined on top so those are the four constants the member state, the state member field it has one of the four variables or one of the four constants and now we are going to look at the method lock so you have four methods or four operations in this door behavior one of them is too long so all the other three methods unlocked, closed and open are pretty similar from this method so we are only going to cover this one but it shows already very clearly on top that you have first the part in the method where you are going to check in which state am I now am I really able to call this method because you see this is a state machine and you only can provide a number of signals or a specific number of signals in that given state when we modeled it as a Java class we had to define the four methods as public and these methods are always available you can always call them so you need to check when this is actually allowed to call that method in the given state so if the door is already locked or if it is open and locked then you can't lock it then you heard it so you check that and you throw it on such a new case then the second part of the method is to update the state value because if you lock it depending on your previous state if it was closed then you assign the locked state to the memory field and if it was open you assign the open locked state to the implementation of one of the four methods so now we are going to look at how this same behavior is implemented with the JPL process note that now we don't see one of four so previously I had shown two slides and already and not all of it so three methods were left out here you see the complete implementation of the door process in one slide so you can see the different states and a different transition so this should already give a clear indication as to what kind of problems benefit very much from this workflow technology from the process language so for this problem it means that it's easier to express it as a state machine versus separate methods and it doesn't by making the comparison between the Java and JPL I mainly want to give you an indication of when it's better to use JPL I don't want to give the impression by typical BPM workflow products that everything is in process everything should be centered around the business process that's an impression that you get very quickly from BPM products and especially what they're trying to do or it's mainly a consequence that they're monolithic systems and they're built to run processes and business processes and workflows but what if you want to do some Java behavior or what if you want to program what if part of the solution is process and part you just want to write Java code that's where they don't mix very much very well in a typical engine and that's why I'm going to try and show you here that with this process language APL is very easy to mix and match processes with Java coding so we saw already the complete specification of the station so now we're going to do something extra we're going to walk you through a JUnit test in which we're going to verify if the process that we just created actually implements the right behavior and at one go you can get an impression of the APIs that you can use to invoke these processes so first you see a static member field which is the process definition so this corresponds to the process that we just saw, to the XML and the diagram image so you see one member variable there there's one for all of the tests in the test suite that we're going to run in this case the XML file that you saw describing the process it was in the file process definition.xml so we load it as a resource and we parse it and we get a process definition object this represents the whole process and now we're going to see a test method in which we can execute this process so the process definition is always static and then we have per execution a kind of data structure that keeps track of where you are in the process but you always remain one process one process description let's say and multiple executions it's the same relation as between Java classes and instances, object instances so let's look at this test method in this test method we're going to create a new process instance for the door process this actually creates one instance of the state machine and the start off that was indicated in the process you start in the locked state so then the actual pointer to where you are in the process that is indicated by the token the token is the pointer to where you are in the process and in order to support concurrent parts of execution the data structure is a tree of tokens so one process instance corresponds to a tree of tokens of course for the door we just have one part of execution one token, the root token so that's what we fetch here so now what we're going to do is we're going to send a signal so this is where you can see graphically the token this is your runtime data structure this is your fixed process so when the process instance is created in the yellow mark part after this constructor the root token is positioned in the start state which in this case was the closed state so now we're going to invoke the signal method which means this is an external trigger so that the state machine will take a transition in this case we're going to look for the lock transition and take it and then inside the signal method we're going to do the calculations until you end up in a new wait state so you might potentially have a number of automatic steps in between but eventually you will end up in a wait state so if you take the lock transition which is here you can see that you will end up in the lock which is another wait state so that's where the calculation stops and the pointer will be updated the token pointer will be updated towards the lock so now you can see that you can persist both the process and your runtime so of course during work in a persistent environment so if you want to be able to work with typically you deploy your processes to the database and they're already there and then at runtime you start a number of processes and provide the external triggers in one transaction so the process is already there and you only insert the token records with the pointers towards the states so then again we're going to okay one very important aspect is that this is a unit test which means that for each test in a unit test it means we're going to create one instance and run it through one scenario of the process feeding in all kinds of external triggers typically this might be with a long time in between because in between the signals you might score the process execution in a real life situation but here in a unit test we're going to feed the external triggers and then check if it ended up in the way state we expect so also this is pretty important and a big difference here between typical workflow solutions and what we do in JPL because we don't have a heavy weight deployment structure you can just write your scenarios in a simple unit test and check your behavior so next the unlock method here you can see the unlock method so if you feed that external trigger the token will be updated and it will point again to the closed state so now suppose that in this scenario we want to call the unlock method again and of course you see that from the closed state there is no transition that is called unlock so you cannot unlock an open door so then you get an exception from the end ok so now you saw already some basic weight states so the capability of handling long running execution in weight states because the door process has four states that's an important aspect of workflow in BPM now we're going to look at the second key feature of the JPL language which is tasks so we're going to look at how a task looks like to specify and also give you a little bit of an impression on the tooling around this process language this is just a screenshot of the designer and this looks very similar as the tools that you see around BPM technologies of competing products only this is a little bit different in philosophy the philosophy is that we target a designer both at the business analyst level but also at the developer's level so here you can see we're in the diagram tab and that's where this is a graphical editor so you can select this task in which case you can have a form to enter all your data and this will translate into XML in the meat and that's what you can see in the source tab as I'm going to show you now so if you click on the source tab you will have the XML similar as we saw before that describes the process but now this is an editor towards developers with code completion and syntax coloring so you don't need to click your way through the process if it's faster for a developer to type in the XML he can just do that and the nice thing is that both of these editors they operate on the same runtime model so there's no rounds of engineering there is no markers or whatever but they operate on the same runtime model that's internal in IDE and you get one file that's saved which is a process file so there's no rounds of engineering direct synchronization inside of the editor so if you change something in the text format in the XML you immediately see it changing in the properties so that's the different spirit of this tooling versus any of the others so now let's look at we were working our way our way towards the task in jml I'm just going to give you some highlights of the features that we offer in terms of task management there's various ways on how to assign tasks to people one of the ways is swim lanes you see here this is the swim lane this task is assigned to the swim lane manager and that means that manager is a kind of process road for this process there will be a manager involved and there might be multiple tasks for this manager person so after the first time when you select a point manager for this particular process that will be remembered and later on there is another task for the manager he automatically gets it in his inbox then there is a notification which means some email integration based on templates so that you have an automatic email notification that there is a task in your inbox here is the link to it there is some priority of course with the swim lane manager there are other ways of assigning it as well so you can have direct assignment to people or to groups which is also quite common or you can just revert you can specify Java class in there and then you revert to plain Java code in which you calculate the users you want to assign it to so you have all the options another feature in tasks is a reminder email so you just specify after two business days start sending a reminder email for this task every four business hours until he did it of course this only has to be done in case the task is not finished then there is other kinds of timers that you can specify for instance you can say in the process after four business days if then the task is not completed yet take this transition alternatively in a timer you can also specify some Java class and say execute this code after four days so in this case you want to take the escalate transition after four days and then there is a number of transitions going out of this task so this gives you a good indication of what kind of features are in there and when it will be easier for you to specify this kind of XML versus coding all of that yourself once you've done that with the graphical designer you can generate some forms for each task the other block corresponds to the task form in which uses one thing you don't see is the task list so people can look at their task list or start new processes once they click on one task in the ringbox they can easily generate this kind of forms in which they can fill out their data submit the task and the process continues executing so this is Danny Consola and workflow participants as part of the tuning around JPL language so far for tasks now we're going to focus on integrating Java code with processes so we saw already wait states and task nodes as workflow constructs in the process but JPL has a number of other constructs as well like start states, decisions forks, joints, process states and so on so it's got a complete list of process constructs that you can use to model your processes and to make them executable but very important here are the last one or if the last one the tree does which means that a big part of the vision is that you cannot specify a process language in 20 constructs or in 10 constructs and be complete and be generic and also that can tackle any kind of workflow problem so we explicitly left open the end so that you can for instance if your business model is set in this diet or in this node in the process I want to do something really strange that might not be a corresponding process construct in the palette of the generic tool what this means is that in JPL they always revert to Java coding to do something really weird if you want to do that so if your business model is set in this node I want to first send an email and wait for something but if it doesn't happen or I don't know maybe it doesn't fit one of the constructs already there you can just type in your code reference the Java class in your code so that's basically the most important use case for binding Java code to processes and that's what we're going to cover now so there's an API for describing runtime behavior and basically on the one hand you can do everything which you can do with Java on the other hand you can access the process variable, the process state and everything related to your long learning processes and also if you're implementing a workflow construct you can determine the propagation of execution and this is also a really new concept if you're just used to sequence of instructions in normal programming language this is something different propagation of execution means if I want if you're implementing a node and you want to keep on taking that transition to the next node automatically without a wait state you just invoke leave this node and this transition invoke a method for that if you say I want to behave as a wait state I want the signal method to return I want to persist the whole situation I only wait for a new external trigger in that case you don't do anything you don't invoke any method and the node will behave as a wait state or alternatively you can start up multiple paths of execution that run concurrently so that's propagation of execution and that's where there is an API so now the node constructs of a process language now the kind of components and that's a very interesting aspect where a process language is no longer just handed to you like these are the constructs that you can use so you have to model your process in these constructs no, it's different like we have already a pre-built set of process constructs components, the node types that are implemented and if you want to do something else you can revert to plain programming to extend that set of components or if you say in our environment we're working in an insurance environment and validating insurance is something that happens a lot so let's build a new process construct validate insurance plan and you can write some reusable code in there and so process construct becomes a component so the quest for UPL is over means that previously the BPM typical BPM and workflow products they tried to build the best process language ever in which you could do anything and I believe that's now done with or let's say we believe much more in a vision where you have each process language being a set of constructs and even that is open-ended so there's no if you hear a big game company saying we've got the best process language ever it means that they only have one language that's how you can interpret that so let's zoom in a little bit deeper on how we can bind process to code first of all an indication to an indication to the use cases when do you want to bind process to code that is for instance in the node if you want to implement node behavior secondly if it's not attached so you have the process graph structure now not in the node but somewhere invisibly for instance on taking this transition I want to execute a piece of code or when you leave this node that's not really related to the graphical structure you just add a kind of listener like when execution goes over this transition you execute this piece of code also for task assignment decisions and timers those are good examples of use cases for binding to your process you might want to build reusable pieces of code that for instance sending an email is a very good example that you might want to do in several locations in the process but of course of course in each different location you have different parameters different configuration parameters so there is a configuration mechanism for this code so let's quickly go through it so the example here is in action we want to listen to the execution taking a transition and in that case we want to calculate a number so there is in JPPL an interface action handler in which you can implement concrete classes and the execute method will be called by the engine when the transition is taken and the execution complex gives you access to all the process state and process variable information so here is one implementation in which you calculate some number you start off by getting a process variable you do some calculations and you set another variable so you do a variable update but now of course you want to reuse that calculation in various places in the process with different configuration parameters and that's where you can just use plain member fields so now when you use this those were the things that I talked about so now when you're building your process then you specify the transition you can reference the Java class and optionally you can inject values into the member fields just by specifying them like this so that you can reuse the same implementation in different situations there is also an expression language which is pretty interesting it does exactly the same as you saw before only there is a different way of specifying what code has to be colored there is a number of number of named objects that you can reference in the process of course the variables are the most visible ones so if your process is a set of variables those are Java objects so with an expression like this you take the variable pay raise whatever object it is and you call calculate number method on there so it's just another way a very interesting way of referencing Java code from inside the process and this is based on the standard Java expression language so one nice thing that could be built on top of that is the decisions in decisions you can specify a condition on every transition in this plane expression language so you will evaluate the conditions and take the first transition for which the condition is true so let's quick round up of the JVDL features so I think it has a superior and modeling and execution environment in which we are able so I just quickly list off this basically you can read it afterwards but there is no other language in itself that covers these kinds of concepts so basically this is on the level of the process virtual machine where you can have any kind of construct or not only construct but any kind of pattern that you will find in the process languages like wait states like concurrent parts of executions like binding it to Java hidden actions those are all things that you might find in the process language and basically this list that JVDL supports is the union of what you will find anywhere else so this is what you also can see by the fact that we support multiple languages the core engine has to support them on all the features that's what a key the key difference here for JVDL and JVDL is the work for languages so a typical JVDL process language features of cost management to get a dramatic other trail process trailers are the process variables and you have plugable node behavior which means you can write your own process concepts also very interesting is JVPM is just a plain Java library and it's embedded so you can use it in your own application it's not a separate monolithic engine you just include some Java libraries you create your tables in your database and JVPM can work with that so it's embedded and you see that sometimes let's say half of use cases for JVPM is when it's used as a standalone product half of other times it's used as an embedded engine and both this JVDL and JVPM in general works on an enterprise Java platform but also on a standard Java platform so you don't need to have an application server you can run it in Tomcat application and it also plugs into various databases because of the hybrid JVC abstraction we can run on Oracle or any other database that you have in your project the plugable services are already explained that we run on both enterprise and standard and private there's no real time let's say unless you come back to it in the questions to compare it to people basically as I already told you JVDL is Java people who have services and they vote to long running executions so it's the environment that is mostly different between the two process languages so the conclusion if you only remember one thing is that JVDL is a good match for Java and it extracts state management from your software and it supports long running processes it's unbearable and JVDL in general is a platform for building process languages we have three already implemented and there's more to come I think that sums it up so we can open the floor for questions if I can hear the question I already did so the question is there's no standardization today okay let me first answer the first because otherwise I forget so the question was standardization for workflow, BPM and all that what's the vision of that so basically there are a number of standards basically there are many standards and they're not really converging so they're also a bit diverse and it's a bit of a fragmented landscaping and standardization but I think there's people as well recognized in the BPM area but it's in fact a web services specification that's one thing so there are a number of standardization efforts in place XTDL with workflow management coalition is another one and they have been working on this for a longer time so those are two process languages they specify the XML we should express the process so those are existing standardizations where I think a standardization effort is missing and where there's no standard is in the binding, in the Java API to implement components for a workflow engine so as I told you before the separation between processor, machine and components what API can I use to implement a workflow concept if there would be a standardization effort around that, I think it would be a great advantage because that would leverage the binding between Java and process languages and that's something where there's nothing non-marriage use for Java or a process language and there's a big gap between them so that's where I think it's missing coming back to BPMN which you also referenced so BPMN is a process language which doesn't focus directly on the XML of describing the process but it focuses more on the graphical representation of the process and it is in that respect a little bit different and what I think will happen is that BPMN is getting a lot of traction so nowadays BPUB is known very well XPDL is not known that very well and what I expect is going to happen is that currently two vendors are implementing BPMN supports of the graphical representation support for BPMN on top of people engines this is not a very good match if you have worked with the combination before you'll see that there's a lot of constraints in BPMN that don't match very well to people on the other way around but two vendors are adopting it anyway so you will get more focus on BPMN in the short future and what you'll then see is that when you're using BPMN it matches much better to XPDL and that's what I think will happen so the focus will shift first to BPMN the graphical notation and then people will realize that this maps much nicer to the XPDL standard and that's what I think will happen all the time does that answer your first question? yes so the question is I talked about the probability of node construct and there's not yet an infrastructure in place in current versions in which let's say that the probability also covers the designer what you can do is you can model plane nodes and reference your Java class in there that's what's already supported but if you want a special kind of XML or a special icon for your specific configurations that's what we can't get plugged into the designer it's definitely something that we envision for the coming future but for now it is only possible to reference your Java class from the current JPL you can already reference your Java class and configure it and this is supported in a generic way but not yet in a way that you can associate forms with a new icon that's basically other questions? yes what was the last part in the database? okay so the question is how are these processes stored in the database and is it tweaked? first of all what we have is a the core essence is a Java library so you work with Java objects that describe the process and the persistence is decoupled from these Java objects so you can always just have your own persistence layer that takes the Java objects and map so that's the basic level then the second thing what we have on a persistence service is to use hypernet so hypernet can map Java objects very well to the database so you can start tweaking the default hypernet mapping that we get out of there without a column or change a column or tweaked it the default schema that comes out of there so that's another level of tweaking does that answer the question? last question and otherwise you could come down and talk for a while okay yes, versioning is in so the question is what happens with versioning you have new versions of the process this is pretty different because if you have an application server and you have enterprise being deployed on there it's always one version of the enterprise being that's deployed because you can always assume that when requests come in they are handled pretty quickly and you get with a redeployment just wait until all the requests are done and then direct new requests so you only have to have one while in processes that's not the case you might have a long running process a legal case that takes two years and then you might have a new version of the process that that's different and so the default mechanism that comes out of the box of versioning is that whenever you start a new process you start it in the latest version and it keeps on executing in the same version when you deploy a new version the new executions are started in the new version and the old executions they keep on running in the old version so that's the default behavior which you can change of course but that's what you get out of the box so and of course you don't want to let's say enforce the fact that the response is migration because that might be tricky in the old process you might point to a node that doesn't exist in the new process for instance so you know that's more tricky the separate versioning is to get out of the box and it also goes to the level of the classes so if you associate the classes with your process you can version those classes as well you don't have to but you can in which case you can extract of which process is executed and you take the right version of the right process thank you very much