The 2022 Camunda Community Summit was held last week (April 26th-28th) and Apex team members moderated three discussions on the "Unconference" agenda. Those discussions were not recorded to encourage free and open conversations, but we have re-recorded the short intro demonstrations we gave to kick off the discussions.
First up, we have Dave Knapp's session on coordinated deployment of process models and applications using the Apex Designer Low Code platform.
Transcript:
Hi, this is Dave Knapp from Apex Process Consultants. For those who couldn't make the unconference session last Wednesday, I decided to do just a little recording of the material I presented at the beginning, just to give you a sense of what kicked off the discussions.
So what we're covering is the coordination of deployment of an app and the processes. The environment that we're working in is a low code tool called Apex Designer, where we design the user experience, the processes and the information model.
As soon as that is done, this metadata is used to generate a set of Angular files, Node.js files (using the Loopback rest API framework) and also, of course, the Camunda BPMN files.
Now when that is done during development, we push that into a container called an app manager. This is a container that runs, and inside of it it dynamically synchronizes the files, does the angular and typescript builds, and runs the application. It also gives the access to the logs and such.
And then in a third window we typically have the app itself. So you can make changes to the process, edit the user experience, change the information model, click the button, see the build, see the run.
And of course over here to the side, there are other containers that this one references. For example, talking to Camunda as a remote engine or using Postgres as the underlying database for this design.
Now, when the design is complete, then we push these files that are generated into source control (we use Bitbucket) and use pipelines then to do a build of a Docker image, which gives us a containerized app that is the loopback server talking to Camunda and Postgres, also serving up the Angular client files.
So that's a little roadmap of of the environment that we're working in. So now let's go and take a look at a little example. So as you see, I have three different tabs here. This is the design environment. This is the build run container. And this is the app running in that.
Now, if we take a look here, we have a task that I have started. So I'm going to submit a vacation request to be gone for five days to unwind after the community summit, and submit that. Now, the reason I did this is note that the review request is the name of the task that is given to the person after me in the process.
So now let's take a look at the process diagram and show that the that is the step. So after submit request it becomes a review request. So you've seen that in action.
Now, if we want to make a change, we can simply do that. Let's say that we wanted this one to be "approve request". So the files are being generated and it will synchronize. And you can see that it's taken out the old user interface here and put in the new one. It's also, of course updated the BPMN file.
Then it's done a server build. It has actually stopped the previously running app and started the new one. And in the running app here, it has deployed the new version of the process to the server. So now when we reload this page and create another vacation request. You'll see that the task is different. So we've actually caused a new version of this process to be deployed, and this new version has the new task name. And of course, all the UIs to go with it have been modified as well.
So that's a quick look at how we do the generation of the files. Let's go take a look under the covers of what's happening here. So in Apex Designer, first of all, you'll see in the processes that this is the vacation request BPMN that was generated from the from the editing session that we had.
We also see that in the files (angular/source/app/userInterfaces), we will see that the review task has a new component created with the right task name and all of the other information in it.
So once we're done with this application, (we basically have been illustrating this part of the process here). Once we're finished with development or at a place where we want to send it to stage for end user testing, then we can simply go to source control here and do a compare to repository. It'll figure out which files are different. Basically, it does the various git operations behind the scenes and shows us the result here. I can make a comment that I changed the name of the review task and commit those changes to the repository.
Now part of what we've got going on in this particular application is a pipeline which when this is pushed up into Bitbucket, it will run that pipeline. There isn't actually one on this particular sample, but it normally would have the the Helm library added on to here, which would generate all the Helm charts for this particular app. I can show you that that in action (we have to fill in some parameters down here), but the source has been committed so we can go and look at that. Last commit is right here and we can jump down to the BPMN and see that we took out the old name and put in the new name.
So that is a quick overview of how we coordinate the release of the server side, client side and the business process using the external task or the external engine pattern. Hope you enjoyed that. And if you have any questions, don't hesitate to reach out to me and I'd be more than happy to answer them. Thanks, everyone.
