The 2022 Camunda Community Summit was held last month (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.
In our previous post, you can see Dave Knapp's session on coordinated deployment of process models and applications. Dave’s session also includes a brief introduction to Apex Designer. Next up, we have Jim Volpe’s session on managing externalized process content using the Apex Designer Low Code platform.
Hi, this is Jim Volpe with Apex Process Consultants. In case you missed the Camunda Un-conference session, this is a recording of the introduction that I gave leading into the discussion. And if you haven't already, be sure to watch Dave Knapp's session first because there's some information that you could use to lead into this one. This session is about managing externalized process context in a Low Code environment. So there's a Camunda best practice for maintaining data outside of your process. When you're running a process, you have to make use of lots of data. And the point is that you don't want to overburden your process engine by carrying that data around within your process. So you just want to carry around the pieces that are necessary to run the process like within tasks, being able to re-reference information as well as to handle task assignment, as well as decisions along way too.
And the low code tool that we use as you saw from Dave's video is called Apex Designer. And the APIs that we use are within the Loopback/NodeJS (backend) where we are calling Camunda as well as our data store as well. And I'll show you details of how those are configured and see them in action. So let's jump into Apex Designer, and this is a simple two step process with a couple of user tasks. So each of these tasks has a task user interface. So within each of those task user interfaces, there is a configuration to dictate what information is read as we start into that task and that information is read from the task as well as from the system of record.
But let's take a look when, when we drill down into one of those task user interfaces, the definition for it, we see a couple things here. Notice that this is the onboard supplier process and the initiate onboarding user task. And then within this URL here we can see that the task ID is carried around with it. And what that does here within this task user interface is within the template - which is the presentation of the user interface - we have this task page component, and the task page component is a shell that includes the things around a task, like being able to complete a task, as well as reading up details about the status of the task and so forth, but also also data around it and the user interface components around it too.
And we'll see it running in a moment too. And then notice that it has a configuration here onboard supplier that sits over here. So we've got our task ID that is referenced in this task page, but it also knows to read the onboard supplier, and then there's a configuration on onboard supplier. And that configuration says, well, we're gonna read it automatically. So right as we come into this user interface, we're gonna read that information.
And then there's this configuration that says, you know, as we read that, we're also gonna read the purchasing admin. If there's one that's stored on it, as well as the supplier that's related to it and the locations for that supplier. And then any of the data that is worked with on the UI, so if we edit a field, then it's saved automatically. And from there, let's take a look at the data model.
I think it's important to take a look at the data sources that we're making use of here. So notice in the upper-right, we've got three different data sources (and they're color coded, so this is a legend for you), Camunda is the first, and that is all the data that's available through the Camunda API, and then supplier repository is a system of record that this application needs to make use of, and then the third one, in blue, think of it as the application data source the information that we just need to carry around within this application.
Now notice that we have references here. So a process definition has many process instances and a process instance has many tasks. So that's all within Camunda, but a process instance has one onboard supplier. So it's tied into our application database, which in turn is also tied into the system of record. So we can read a supplier in its locations through those other objects.
Now, one key point here is that the onboard supplier has a configuration for what data gets exposed within the process. Let's take a look at the onboard supplier object and I'll show you what the configuration looks like. So there are a couple parameters here, date submitted - that's when the process started, and then a review comment if the reviewer cares to provide some feedback, but we also have some relationships - both to the system of record, as well as to Camunda data.
Now, the configuration that I mentioned fits within this mixin, so this process business object mixin includes a JSON definition, and you see that it has the process name, and then it has a filter, and that is a Loopback filter which allows you to [control the] read. As we read in this onboard supplier object, we will also be able to read in the supplier and the submitter that are related to that onboard supplier.
Now that information, we're not carrying that over into the process engine. So we're not sending that out to Camunda. It's these exposed paths here in line six, where we have the date submitted and the submitter email and the supplier ID that are being exposed to Camunda. So we'll take a look and see what those look like in the running application. In fact, we can go ahead and do that right now. So this is the suppliers page. And what I'm going to do is just click on the add here to start our onboard supplier process. And notice here that this is the first user task within the process, in fact we can see the process diagram and we can see that we are currently within the initiate onboarding task for the buyer.
Let's take a look at Camunda, first of all let's refresh this page and we should be able to see that we have this process instance that was just started moments ago, and we have a couple parameters on it. So we have a date submitted and a supplier ID. Those parameters were set so we actually created the supplier before we even populated data in it. We created that preemptively and we also have that date submitted. So those are two parameters but we'll add one along the way, and let's do that right now.
I do have the network tab here open too so you can see kind of what's going on as things go through. Right now we're patching the, the data for that supplier. So you can see the payload here. And this is a call to the loopback API for, for that supplier. And the payload is just setting the, you know, using the ID, but setting that name that we just set and the next one would be setting the employee identification number. And we can stop right here for a moment (we could add locations and so forth too) but if I save this for later, what it's doing here is it's updating the process variables. So it's just sending a call to the Loopback API, to onboard suppliers and saying, hey, update the process variables. And then the next one here is just to get the list of tasks.
So that, that task is still assigned to me and that's in that list, but let's go back into cockpit and let's refresh the page and notice that we have a submitter email. So now that I've started really working on the task, it has assigned my email address to that onboard supplier object, and it is exposing that in Camunda. So that save for later or completing the task, would've also exposed that data. It would've sent the update process variables too. But in fact if we come back in here, we can continue to add more information here and save it. But there's not gonna be too much that goes on within the Camunda instance, because we're only carrying around those small pieces of information to reference.
So that is my quick introduction to using Low Code, to manage externalized process content. I hope you've got something from that. And if you have any questions that you'd like to run by me feel free to reach out to me anytime.
Thank you.
