 We are going to talk about Kogito. If I say during the plantation, Kogito is the same thing, we just didn't settle on the pronunciation yet. So it's about building intelligence service applications. I'm Dominik Hanak, I'm a quality engineer at Redhead. We work as a quality engineers on this project. And this is Marian. I'm Marian, I've been in Redhead for more than five years and I've been working mainly on JVPM and rules and now on Kogito. Yeah, so we're in Redhead, we collaborate closely with engineering, so that's why we kind of stepped up and said, let's give up, let's have a promotion of our project and we are here to give you talk about Kogito. So the goals of today's talk are following. So we want you to understand how the Kogito project can be used to build these intelligence applications. We want you to understand the motivation for Kogito and the needs and why the Kogito was started and why it's like a next step on the traditional JVPM. And we want to showcase the developer experience using Kogito to build the applications. So we want to give you this. So let's start with short recap. So this is the business policy management theorem but no, we won't go into that. We will just briefly show you what was the legacy BPM and like, so you can understand the transition. So as you may know, this is basically the BPM cycle. You analyze your business, you create processes writing down, then you design them, implement them. Then you deploy that, you can monitor and optimize. Yeah, so you just want to have your business and you want to see how it performs and optimize your processes based on that. Yeah, so here's the picture. Just to show you better, it's basically it's never ending process. It goes over and over again. And yeah, so the traditional BPM basically, we are working in JVPM rules communities. Anyone familiar with them? All right, cool. See some hands, that's good. So JVPM rules solve the traditional BPM. Basically we provide a large business process suite. Basically one big minority application where you have engine, where you have designers for your processes, where you have monitoring capabilities. No, basically it's very heavy weight. It's hard to scale, like not easily scalable because only where you can scale it is using more key servers. And the development cycle is kind of long, so it's not agile, and agile is very popular nowadays. So based on the basis, you should understand before we move to Kogito. So just to show a picture, how it worked before, you had business process suite, right? Where you design things, then you deployed your processes on key servers, where you have basic execution, and you can connect databases, but you can scale only here in this area, right? So, oh, that's the points, nice. Oh, so you can only scale to the right and left here, and you have big minority application at the top. So that's not really nice. So that's why we have Kogito, or our great engineers came up with Kogito. So, you wanna take this one? Yeah. Okay, great. So what we did with Kogito, or what we are trying to achieve here, is that since the previous application or previous deployment wasn't really well built for cloud, let's say you had everything in this, what we call key server, so this is the execution part. And if you wanted to, for example, scale, scale our application to serve more requests or to better balance the load, you would be scaling everything which was inside. So, as Dominic said, it was pretty monolithic. And what we are trying to achieve with Kogito is that it is already designed with cloud in mind as a set of microservices. So, basically, the key server you saw is basically split into parts. Each part has its own responsibility. One, for example, does the execution itself. The other one is doing what we call in the JBPM auditing. So, basically, what happened and when. And the other parts, which handle, for example, timers, there is also another microservice, microservice for that. So, this is the first thing. Of course, if you split something into these components, it means also that you can scale independently every part of your application. So, for example, if you want to, if you don't, for example, for auditing, you generally don't need scalability, let's say, the main point of scalability or where you want to scale is in the execution part. So, now you are just scaling the execution part. For example, you don't use timers in your business processes, for example, or in your automation in general, and you don't need to scale that. So, you don't even have to deploy it. Whereas in JBPM version seven, if you scale basically the key server as a whole unit, you would be scaling also this timer service and other things you don't need. And also, the other thing is that, meaning that it's now, I would say, from the developer point of view, from the developer point of view of Kojito is better organized for us. So, we can also work more in agile way and streamline, we also have streamline development, I would say, because right now it's not, as I said, just one monolithic application, you can work more independently on different parts of the technology itself. And we will show you. But if you compare it to the previous one, where you first deployed, you have your suit, you designed something there, there is like really zero cap, like there is not really nice versioning system there, or the collaboration is really hard. With Kojito, the development is really streamlined. You can easily integrate it with any GitHub or Git versioning system. So, it really helps you as a developer to go like rocket speeds with your application. Yeah, and when it comes to some new features, for example, for Kojito, we are also investigating a possibility of server as workflow, which means if you want, for example, AWS Lambda or something like that, or function as a service. So, this is what will be made possible by Kojito, probably. And the final part, which is pretty big also for Kojito, it means that now it's completely domain-based. So, we no longer interact, for example, with your business process as a map, for example, where you have for your variables. So, let's say you have a travel agency and you have, as a process variables, you would have for your business process, the process variables would be mapped as a simple map, so key and value store. Now, it's domain-based, so it means that each process instance has its own basically object, which is no longer named hash map, for example, or it's not a hash map, but it's one specific object in case of, for example, your travel process, which we'll see in a minute. It's called just travel. And so, we are directly interacting with the domain you are automating. So, basically, how does the architecture look like on Kojito, roughly? Basically, the only part which you need or why you are building your Kojito app is the execution part. So, you have your Kojito microservice. We will talk about it later, how it's built, and what does it run on, and so on. So, basically, you can even have your decision or process or planning as a service, which means it usually uses also Infinispan as a data store, so it has persistence. It has some states to it. Or you can probably, you may decide that, okay, I don't need any state. I just need to quickly make decisions, run some rules, and so on. So, I don't need persistence. So, in that case, it will be acting like a function show. So, if you need to do a decision, it will quickly spin a pod, not use the persistence at all, do the decision, reply with a response, and that's it. Yeah, so, let's say you would let's plan a simple service for your business where you wanted to decide which employee gets bonus and which not. So, you write down some simple or you write down a simple process with one gateway. Like, if it's, like, he can get a bonus. He shouldn't get a bonus based on some rules. And they just bundle that using Coquitur extension for Raku's, and you will have your service. And that's all you need. One, it has one state. You run it up. You ask him, can this employee get a bonus? No, I don't, yes, or no one, that's not. It's really simple and fast. Yeah, so, and then you can start building your infrastructure. So, in case, you probably, in case you need, for example, auditing, so you want to know what is going on with your processes when some, when and who did, for example, who completed the human task or did something with your process or with the domain object in general, you can also spin in the data index service. We call it data index service, which usually, when something happens in your execution environment, it emits events and store it in in-span and then we have GraphQL API, so you can query what you want. So basically, if you know JBPM version seven or rules, it is basically the audit log for the Cogito. Next thing you can do, if you, for example, use timers, what are timers, if you don't know, it's something in your process. For example, if you are painting a body of a car and you need to wait a little bit to, so it can dry out, then you can employ timers. So, okay, now in our process of building a car, I need to wait, for example, 30 minutes or more to let the paint dry out. So you can, if you are using the timers, again, you can spin another microservice for timers. If you don't use it, you don't even need to have it deployed on your OpenChift. Next part, which we also plan to have is some, basically UI or process management. It was called in JBPM seven, basically, or authoring, where you could, for example, run your process through UI, so we would click start this process, and then start another process, and then show me when was it started, and so also, basically, this is the UI part. And this inbox means that this is basically task inbox, so it's like, again, some management service for him task. So, again, UI, which usually connects to the execution part, and you can control to claim tasks, complete them, and so on. And also, yeah, of course, finally, as with previous JBPM seven deployment, you can also use SSO for managing authentication of all these services. Input apart about, that's mine now, that input apart about this is that all you need is your domain, and you don't need these other things if you don't want to. You can easily plug it in, and if your business suddenly needs some monitoring, some index service, you will plug it in, but your application still stays the same. So it's very easy, it's scalable here. All right, so let's talk about tooling for a bit. So when I say tooling, I mean design capabilities like BPM and editors, DM and editors, editors, something where you can easily model your processes or develop rules. So in old life, we had to be BPMS here, so it's a very huge application that covers full business process, business management cycle, so you can analyze, design, implement, deploy, run, and also monitor. So, yeah, these applications are slow. In case you wanted to just model a process, you still needed the whole application, so it's not really good. These applications tend to be slow because they are huge applications, so in old life, it's like this. You have one business here, you can do everything inside. But what if you just wanted to fix some business process that some other that will predict what would you do? So we've got it, we wanna bring a new life of tooling. Basically, these editors are now streamlined as a microservices. That means that you should probably, you go to, I don't know, you go to a webpage, somewhere, and if you open your editor where you can import stuff, you can import a business processes and edit them, download them, possibly even directly moving them to GitHub and commit something to your visioning system if you want. So with tooling for Cogito, we are talking about something called Omnichannel Support, where basically, we would like to provide, sorry, we would like to provide different channels for you developers so you can easily work with the processes and other assets that you need for your domain. So currently, we target VS Code, we provide some VS Code extensions where you can open BPMN files and DMM files and instead of playing XML view, you will see the editor and you can work with the process and model it, et cetera. So that's the first channel. Then we also wanna provide browser extensions. For example, current, we are at alpha stage right now, but we provide GitHub integration where if installed is extension, you can observe and modify these processes directly inside the GitHub. So we inject the editors inside GitHub and when you open a BPMN file or DMM file on GitHub, you will see the editor. And you can actually directly model it on GitHub. You can change variables, edit it the way you like and then submit a pull request easily. So that's very nice. So next channel for us is online editor. I will show you after. When we were showcasing the demo. And I'll mention desktop here, but there's really no stages of planning or maybe not we're mentioning at all. But when I say only channel, the idea is that whatever channel you choose from these, you will be able to work together with, like you'll be able to model something in online editor and then use the VS section as well. So just the developer experience, we plan to make it really streamlined between these extensions. So whatever channel you choose, you will get the same experience. So what are the advantages of this approach? It's lightweight. So you will have only business process modeling if you want only DM and modeling. If you want it's fast, compared to previous version, this version seven, the large application. Yes, this is really fast. You just open VS Code Marketplace, you install the extension and you are ready to model. You don't need to deploy application on EAP, wait for it to load up, then plug in some other services so you can, this is really fast. You have an installation that should be together, but yeah, it's really easy. Also, it will be on Marketplace. So browsers have Marketplaces, VS Code has Marketplaces. So you just install it and you are ready to go. And the battle proven, well, the editors itself are from version seven. So we had to do some, we did some modifications on the code sites to let them run client side. So, but it's still the same editor. So the version seven editors are really well tested. They have been around for some years. So basically we are just letting you use this battle proven editor in different channels. So yeah, it's well tested I would say. And as I mentioned earlier that we wanna give you the best developer experience possible so these channels are interconnected. So there is some, for example, there is a link if you model something in, if you open the editor inside GitHub, using the extension you can directly link yourself to the online editor, we remodel it, change it and link back again. So just some nice features that we wanna add. All right, so what is the current state? Current state of the tooling is that we currently offer BPM and DMN modeling extensions. So you can check the releases on the URL. There is also online editor currently with BPM and DMN capabilities. And I'm just mentioning that they are both written in the language we use is React and TypeScript. So if you are fans of these languages, come and contribute, you will be welcomed. So yeah, that's about the tooling. And now I'll hand it over to Marian who will be talking about runtimes. Which is, so after you have your assets designed, for example, the process definition and so on, it's time to run them. So for as a technology stack, we currently use like running, of course, Java, so we are staying on Java. Then for execution environment, let's say, or for frameworks, we use Quarkus. We also support native images in Quarkus and Spring Boot. The thing is that for Quarkus, we have custom Quarkus extension, Kodito extension for it. And if you are using Spring Boot, there is a Kodito Maven plugin which does basically the same thing with regard to code generation and so on. So that's for running, for interacting, let's say between services and for persistence, we use InfiniSpan as a data store so we no longer use relational databases. Then for eventing or like propagating events from the Kodito app itself, use Kafka and for querying them from the data index service, we decided to go the GraphQL way. So it should be also pretty fast. When it comes to other new technologies, for example, for timer service, we use reactive streams. So we hope that this will solve the issues which are pretty common. For example, in business automation, when you have thousands or 10,000 of processes and you have to trigger something at a specified time. So for example, you want to recalculate interest, for example, in a bank. At the end of the month, sometimes after midnight, we want to do it as fast as possible. You can quickly have tens of thousands of timers waiting to get executed. So this was a pretty tough job for JPPM, for example, in version seven. It was manageable, but it took some time and we hope that using a reactive stream that everything having asynchronous will solve these problems. For example, in job service. And then from the way we are building your app, once you design your process definition and your assets, decisions and so on, we heavily depend on code generation, which means that in order for your application to be domain-based, so you don't want to interact with just key and values, keys and values. You want to directly interact if I'm doing, for example, if I'm booking flights, you want to interact with flights. If you are doing booking.com, for example, you want to interact with bookings or with hotels and so on. So everything is extracted from the process definition and from your assets, and then domain is basically generated from it. So if you want to start developing the application or developing your Kojito app, we have a few possibilities. So links will be at the end of the presentation, but first you can explore our Kojito examples repository, where we have some examples of really simple application, which can be really run quickly. And then you can decide if you want to go the Quarkus way or the Spring Boot way, basically. So you either use Quarkus Kojito extension or Spring Boot together with the Kojito Maven plugin. So for example, in Quarkus, you can just call this Maven command, which will add you the Kojito extensions and it will create basically a new project for you. And yeah, the application is created. So now I think we can move to the demo. So of course we won't be building the application from scratch here, because it takes obviously some time to design your process and so on. So we will be showcasing the Kojito travel agency. One, I think it's the second version, which means that we will also have a persistence running. So what's the domain? Domain for the travel agency is that you have a trip. So that's basically your travel somewhere. You have a traveler, you have a hotel where you can stay, flight and address, which is basically connected with the trip. Yeah, so the process starts like that. You generate your application, your skeleton of application using that command in previous slides. And the first thing you need to understand is like what business am I working for? So if I wanna do a travel agency, I will probably look at some trips, see some travelers, see some hotels, maybe flights, I don't know buses, but let's keep it simple in the example. So you just make your domain models. So this is like playing on Java objects. You just write some Java classes, you add the attributes, get their setters. Basically that's your domain. Yes. The other thing is you can apply some decisions. So basically they are usually with Kojito, they are backed by rules. So you can opt for directly the DRL files or in this case it will be the decision table or you can run DMN and so on. So this will be used for deciding if a traveler needs a visa application or if the traveler needs to apply for a visa depending on the country where they travel to. And then you start basically designing your process definitions. So yeah, and our process definition will be like this. So at first we will input some trip data which means you will feel a simple application or a simple form where you say who you are, your contacts, where do you want to travel, when and so on. Then the application will try to decide or it will decide if you need a visa based on your nationality or citizenship and the country where you are traveling. Then if you need a visa then a human task will be created for somebody, let's say somebody in the travel agency or somewhere which will either apply you or apply the visa or they will just cancel your date, let's say. And then you can proceed to booking hotel and flight and basically the last thing is just you can just confront travel. So this is like a really basic process definition. So right now we can show the application. So yeah, I will directly open the process definition. So this is the VS Code. It has the extension for modeling installed. So when you open the process you can see it like this. Data is almost full features. We are working on adding more features but you cannot properties, you can modify the task if you want and you can work inside the application. So while you are working with your domain models and editing the services, et cetera, you don't need some other application for editing the processes as well. You can just directly edit them in here inside the extension. So this is just the process designer directly in the VS Code. Then we can, yeah, here is the process definition. So here is the visa check. Then basically if you need a visa you can apply for it. If you don't need, you just progress further and then there is a booking of flight and booking of hotel and confirming the travel. These two things are also sub-processes which we have here which are really advanced. Yeah. So it will just call a service to book flight and book a hotel. Yeah, so basically that's it. And the services itself are defined here. So it's a really advanced service as you can see. It's basically a CDI beam which will be injected into your application and it will be automatically found and run when the process is being run. And then the domain itself, so here we have a traveler, trip, hotel and so on and so on. So basically that's your application and finally for the decisions, I think I can... For exolas, you need to open it from them. Yeah, I'm going to open it. It's just a basic set of rules like when a user, or when the traveler is from, let's say, Poland and he wants to go to America in his visa, right? So the service just retains that. So it's using the rules. So it's a decision table format where you have some condition. I don't want to show that. So it's a decision table format where you have some condition and action and some input data which are based on the decision. Yeah, so basically here it is. So we are not yet ready for production, as you can see, as we currently only know if Polish people can apply for visa or not. But basically it works. So far we don't need visa for UK until the end of the month, probably. Then basically this is just a decision table, you may know, but basically it means that when there is a trip, and a trip is to one of these countries and there is a traveler who is of this nationality, then we will just decide if he needs or he doesn't need a visa. Basically that's it. So back to the VS Code. And right now we can just show the application running locally. So these are pretty normal commands. You just run it. Compile Quarkus Dev. So we get a Dev server from Quarkus. So you can see, yeah. It supports other reloads. So developing this kind of application is much easier with Kogito. Let's say we would found an issue in our rule file. So all we need to do is change the rule, fix it and up on the reloads we will have the rule fixed and the application will be working again. And let's say we want to decide, we want to also capture, I don't know, some other attribute here in this table. We just changed the application and it reloads. It's like, you know, excuse me. So basically if you need to speed it up again it does it for you. I think if you know Quarkus and the other reloading stuff it will be pretty comfortable with it. So it works also here. So here we have our traveler. This will directly post basically a JSON file to our service and it will create a new process instance. So a new instance of our stay. So let's say we want to first do without visa. So we are going to... So no visa is required. So we are already a task on from travel so we don't have to apply for visa again. And when I click details it will directly get request to my service with the number of the process instance if you read the ID of the process instance and retain the whole domain model basically or the whole domain for my process. So you don't need to fetch this separately that if I have in a process definition as a separate variable, for example, a hotel you don't need to pull just the hotel flight and then travel and trip and so on. And everything is generated for you. So you just provide your domain models, the cookies will generate the rest and points for you. So basically... You are not writing the rest. For example... Okay, now let's say the flight 555 is fully occupied. So I will just quickly show the other reloading. So of course I do now 666 and then I just refresh it. Let's say we want to go the same way. It should be... Yeah, so it's already updated. So that's pretty basic stuff. And so this is basically a developer experience on local. I can quickly show the generated code. It's generated so it may not be that readable but still you can, if you want, you can find it here in target directory. So for example, for travels we have a travels resource which is generated and basically you can see... If I want to create a new process instance, so a new travel, it will directly post... It will do a post request with the travels model and it will create basically a new process instance. And this travels model is here. So we have traveler, hotel, trip and fly there. Yeah, so this to the local... Yeah, you can then package the application as normal so you will have your own executable jar of the application and then you can start deploying it to OpenShift. And that's where the fun begins. So we can try to... As we still have some time, I can try to deploy our application which is the same application which I have on local but I already have it on GitHub. So we have a cogito operator there which will basically do S2I build of your application, then we package it into the runtime image so it's really lightweight and run it on OpenShift. And we have also cogito CLI which means is a CLI... You can use with this command. You can create directly your new project which will pre-install the operator in your project or in your namespace on OpenShift and then we have some commands there to quickly deploy or service-delete-service-delete project or install, for example, infrastructure if you need to finish spend job service and so on. So I will start creating this. So let's say we want to create a new project. By the way, if something doesn't work, don't blame me, blame Guy over there who wrote it. But... Yeah, it just works, as always. And now, yeah, we have a project here. You can already see that the deployments are coming which means we have a cogito operator already starting there. Yeah, so it's basically the infrastructure or the environment that is being installed so you can deploy the application there. And if I go back to here... Yeah, so it's starting up. So just one thing that we didn't mention is as you see in the hot world, you see that the application spins up really fast once you have it compiled. So in case you are running into high-tier finger-winger service, you can just spin up another hundred ones like this. So that's like a very good feature of cogito as well. Okay, and now we can also show the cogito CLI. So basically, these are the commands you have so basically it's creating your project, this project, display the current project, so pretty easy. You can also do, for example, if you don't know what's going on, what's going on as an argument here, you can input a bunch of parameters there so you can tell it from which branch you want to deploy your application and so on. So I think already it should be... Yeah, everything is basically running. We have infinite span operator for infinite span. If we need it, click load operator and so on. So right now we can start and try to deploy our application. So basically we are deploying the service which will be called travel agency from this URL. The directory is just because we have different Maven modules there so we want to build this path. So version zero two. I will just delete the project because I want to do it in the currently selected project. Yeah, and this is just the invariable to speed things up. I'm providing just our internal Maven mirror to be able to build it more quickly. This is just a normal Maven central mirror we have there. Branch will be DEFCON and I want to install infinite span. So that's it. And now, hopefully... Yeah, so application was created. We can briefly check it. For example... Yeah, we already have a builder there which will try to build our application. It may take some time, but... Yeah, so it's already running. And while it's running, we can probably move on because it may take a few minutes. So as you can see, the Kojita cell is pretty easy and you can of course deploy your application via normal ODO or OC commands, but we encourage you to try the Kojita cell because it's much easier, I would say. And you have the power of operator there and so on. So where you can find Kojita? Yeah, so this is basically wrap up of the showcase. You can find Kojita in these links. The slides should be shared, right? Yeah, so you can take it and take a look. The example that we were showing is... Again, in GitHub, you can check it out. There are, I think, six parts. Each part adds something new to the example. For example, in Second, you have the InSprintSpy right. In Third, you have even the data index. Not really sure, but check it out. And there are also other examples in this second repository. So if you guys want to contribute, find us on GitHub. There's a key group and search for Kojita projects, Kojita repositories. There's quite a lot of them, so we don't link everyone. Just go to the key group and type in Kojita to the search bar. You will see everything that is related to it. Okay, thank you. Yeah, so now we probably have time for questions. As you can see, the application is being deployed, so it's normal Maven run, or normal Maven build, and afterwards we should see the travel agency runtime bot running. Yeah, slight new synchronization. Yeah, it's okay. Okay, so do you have any questions? Yeah, we have a lot of time for questions, so if you didn't catch something or something wasn't really well explained, so go ahead. And if you want to see more in 30 minutes, there will be another Kojita talk, which will be basically about the more advanced, if I'm not mistaken, example of the Kojita travel agency, so it will be more focused on cloud. So this was like more developer experience, how to get to the cloud, and now in 30 minutes it will be more advanced, I would say. Yeah? I did miss the beginning of the presentation. Okay. What's the value point of Kojita? Yeah. Okay, so the question was that, what's the value proposition of Kojita? So you want to answer? Oh, sorry. Should I? You can. Basically, we can show you the, basically this slide. So before we had the Jbpm versions, or right now we also have Jbpm version seven, which is based on, if you do work with it, which is based mainly the Execution Sparrow key server, which runs on EAP. It's pretty heavyweight application, and the biggest, I would say, the biggest drawback is that if you want to scale just part of your runtime, and you have one key server, you have to scale all the whole key server, which is a big EAP application, let's say. So for example, if you don't use the timers in your process definitions, you don't need timer service usually, basically the code is there, it's not maybe running, but you are still scaling the whole key server. What we are trying to achieve with Kojito is that you can basically build your application in pieces, or your automation in pieces. So for example, if you don't need timers, you don't need to even have it, because it's a separate microservice now. That's one thing. For example, if you don't need auditing, so you don't need to know what has happened to your processes, for example, or what was the history of your process execution, you can also shut it down, for example. So I would say that, yeah, another part is other than it being, like, now highly scalable, so you can scale various parts of your application, now it is also domain-based. So before you were posting, where you were issuing the pull request, where you were issuing the request to your service, to key server, it had to be generic. So it was basically a JSON or XML file where you had a key and value, key and value, key and value. I want to send this to my process. Now, since we are depending on code generation, now it's basically everything domain-based. So we are no longer interacting with maps and key values, but you are directly posting there, for example, in this case, travel, regular travel, JSON object. And you also get the travel JSON object back. So you don't have to parse it, your UI can be also tailored to a specific domain. So I think that's the biggest, biggest, like, achievement here. Yeah. And, yeah, just to quickly show you... No more processes, just domain. Okay, this is the proposed cogito, let's say, architecture, roughly, and this is how it was before. So basically, you could... You had one big UI, usually, which was also running on the EAP. It was called Workbench, or it's called Workbench. And then you were just deploying everything to key servers, which could share the database, or they were just split. But basically, you could scale only these microservice... Yeah, it's not microservice, but you could just scale the key servers, basically, which could take a lot of processing power and memory and so on. Okay. Okay, that's it. Thank you very much for your attention. We still have ten minutes, so if you want to... Thank you for the last part, and that was... Ah, yeah. Yeah, it's okay. Yeah, so it's running already. We can share with the pod. Okay, and now... Networking routes. Yeah, so here is our application. So basically, it's the same application, but now running an OpenShift. Yeah, maybe if you want to... You can show the travel endpoint. Ah, yeah. It should be also here. Yeah. So basically, this is the JSON which was returned. I will just show it in Firefox, probably, because it has better indentation. Yeah. So here we can see that we directly received the JSON. This is just an idea of the process instance. There is no flight yet. Trip is to New York. Hotel is not assigned yet, and here are the information of travelers. There is no, like, the name of the variable and the value of the variable and so on. Basically, it's just a really... A JSON object tailored for your domain. Yeah, this maybe kind of extends an answer to your question that previously you would have a process ID and you would basically get the process. Like, the whole definition of the process instance, but here you just get the domain you actually want. So instead of getting the process instance definition in a JSON format and extracting the variables from the definition and then working with them and monitoring them, checking what happened in the process, you just have your domain. So it's kind of an objection. Okay. All right, so are there any more questions? Thank you very much.