 that will be backed with a certain cage. So you will see in a minute that we will have like a business rules archive that will actually contain all our business rules for qualifying the bank loan. Then we have another business archive, or knowledge archive that will contain the processes for different types of loans. So we have a basic loan that requires a single person approval. And we have a long-term loan that will require manager approval and might require additional special terms to be set up. So a very simplistic view at the bank loan system to apply, to qualify, and to approve it. Like a free major steps in the bank loan system that can take. And of course, in reality, that would be way more complex. But just for the sake of the demo and be able to actually show it, I completely simplify that. So first step is that the applicant places a loan request. By loan request, we will see a certain information that the person needs to provide. So provides just the data and just drops the request somewhere. Then we have a bank system that is actually taking the loan request, evaluating that and qualifying. Is it, maybe it's so low risk loan that it can be out of proof. We don't have to involve anyone else. So the bank system can take the decision itself. But maybe it's a higher risk loan or long-term loan. So we need to qualify it and we need to start a certain steps that need to take in the bank itself to make sure that the bank represent that it's approved or rejects the loan. So there will be a different steps included. If we start moving that into services, then we can divide that as those three steps into three services. One is the apply for loan service, which usually will be like a UI system that accepts, no allows user to put or enter the data that bank requires. Most likely validate it and pass it along. Then we have the evaluate loan service. And last but not least is the process loan service. So this is where different steps might take place. So if you go into a bit of a details of the services, so yeah, main entry point. Whoever would like to get the loan, go to that system, enters the data, giving the applicant name, monthly income, loan amount and the duration for how long you can take the money. So this is again the what? We just define the application, loan application, nothing else, so attempting to get a bit of information from the applicant to be able to process those. Evaluate, so this is the business rules. This is where we actually define what can happen and if certain criteria are met, something else will happen. So if we provide the data, that there is a very low risk loan, like below 1,000, then we can directly auto approve it. We don't have to involve anyone. If we have something that the amount for the loan is more than 1,000 and it's less than five years for the duration of the loan, we need to include a default bank representative that we just check the background of a given applicant to make sure that it's not a risk client or something. And then if we have a long term, which is more than 1,000 and more than five years, then we need to have a special staff to include as well. And this is why our rules and we qualify the loan. And then we have, depending on the classification of our loan, we can make a decision on what process or what steps needs to be taken to actually drive the loan till the end. So then we have the basic loan department that is just bunch of guys that's sitting there and evaluating the loan request for the basic operations or low risk, low amount and low duration of the loans. Then we have the long term loans department that are different set of people that will have different set of steps to carry on with the approval of rejection. So now if you start putting those services into your environment, you start having like a free individual services that do not have anything in common. They are not dependent on each other. The only thing that they have in common is the data that they work on. The loan application, that's the only thing that they actually have in common. So they just drop staff, pick up staff from the even bus, nothing else. So if you start looking at how it actually works, so each service is self-contained. Everything that that service needs to operate has inside it. It does not care if something else is available, it does not care if that API is of that version of that version. It's completely self-contained. As I said, knowledge-driven services are backed by the Cajor. So to be able to start a knowledge-driven service, you need to have something that actually brings in the knowledge to you. And yeah, and again, services talk to each other by exchanging data. And thanks to the vertex even bus, this is a very simple way of exchanging data. The only addressing schema in vertex even bus is just the name. It's a simple string that defines where you're actually sending data. There is no API, there is no advanced interfaces that we actually need to understand to be able to exchange and communicate. You just drop the data, that's your interface. Services can be added dynamically or removed dynamically. So you can start as many service instances as you like and you can shut them down and start them up anytime. There are no, no, they are not interfering. You can start a single service with specifying how many instances inside should run it. But at the same time, you can start multiple JVMs that will host different instances of the same service. And they can be anywhere in the network. All right, so let's go to a demo. So before, let me just, all right. So this is the key platform. The knowledge is everything platform that allows us to capture in a unified way our knowledge. So this is a web UI, so you can just go into project altering. And here we have our, this is our long term, long process, a very simple one. It computes the monthly rate. It asks for the manager approval and if manager approved it, it might go either to the accepted notification. So we inform the customer, the applicant, yes, you got the loan. If it's not yet approved and it requires some special terms to be set up, there is another task that will be assigned to another individual in or another group in your department that might be able to handle that and decide what to do. A basic one is even simpler. We have the cloud verification. If that person approves, it's not, it's not send notification to the customer. It's not pretty much the same, but not really happy message. And if we look at the rules, there are just three rules that actually decide is it out approved? Is it basic loan or is it long term loan? Just by evaluating the data that we send. We just grab the element that we have. We got from the event bus. We checked it. We can set, as you can see, I don't know if you can see it. See if I can, is it better now? So we can set a certain attribute on the loan application that will be then when sent over. This information will be already sent to the other parties that will actually work with that. So we just mark it as it's not approved and we say it with a small typo in it. It should be explanation. That it requires basic approval process. So we carry already information about what the rules that the Y has evaluated to. And then the most important thing is our loan application. This is a Java class that has a certain attributes. So we have three pieces that brings in our knowledge into the runtime environment. We have our data that is represented as a Java class. We have our business rules that are represented as a rules language. And then we have our business processes represented as BPMN two processes. All right, then let's see how that works. So we have three services. I will try to zoom in, zoom out to be able to show more. So we can, in the first, let me use the technology here. Here, we have our vertex module that relies on the loan rules configuration which actually just brings in the information about our cager. And this cager actually will be built from within the key workbench that brings in all the business rules. The business rules are here. So here we have our evaluate loan service. Second one is the loan process which is built based on the cager with our two business processes, basic loan and long-term loan. Last but not least is our client. And here we will see different, we will see polyglot support for it. So we start with a simple Java client. As you can see, what's nice, if you can see it, it's a Java. You don't have to compile, it runs the source. Vertex will do whatever is needed to actually run your Java, but you specify not the class itself, but the source. So let's start our services then. So we're starting in clustered mode, so the services will talk to each other. It deploying as you can see, hopefully I can make it bigger. Can you read it now? At least to some extent. So we deployed a container with this group artifact inversion. This is a main structure. So we deployed the bank loan rules as a cager, as a backend for our service. The rules vertical started, so it's ready to run. All right, then we do the same for our process. Again, JBB, sorry, bank loan process. This is the cager. We started the JBB and vertical. So now it's up and running. So now we have our, where is it? Here, our client. The client, I will show you the source of it, it is a single short client. So it just generates a loan application based on random data. So it will generate random amount, random monthly income, and random username that is actually requesting the loan, and random duration of the loan. So that way we can see a different rules being evaluated in different processes being started. So we're starting this, started, and as you can see in the dual smart, we created a loan application for John with Java single loan request as a request ID, income 2000, requires basic loan approval process. Then the rules evaluated that they're given loan requires a basic loan approval process. That means that there should be a process started for it. We don't have anything printed out here because since it's basic doesn't make sense to print out anything. But we can go here, see if we have any process instances in the tasks. And we have the basic, can you read that? A clear verification for basic verification for loan requested by John. So that already came into the business process management platform and started the task for Claire. That person can then go and evaluate the details. So we have the applicant named John loan amount 7000 monthly income 2000 duration two years. And we can either approve it or reject it. Simple as just, can I do that? So I claim, so now it's assigned to me. So now I can make a decision if I approve it or not. And it's done. Then, so this is one shot. You don't, that's just a simple thing. So now let's try to use another one that sends a new request, loan request every two seconds. Again, it's generated. So you can see how much staff there are every two seconds, something new is coming. New requests coming into, same will be here. As you can see, different names, different types of basic verification follow, manager approval. So it runs constantly every single, every single, every two seconds, we create a new business process. It just constantly runs. So here we're calculating monthly rate. This is for the long term. And here you can see, you can't, that we have auto approved as well because it's below 1000 or 1000. So it's auto approved and no process is started. The role system decided, yes, this is low risk loan. Let's approve it immediately. There is no need to do it. And you can see that the request ID is different because it's a different client. Different client generative. So the client is actually when sending the request, can again listen to responses. And as soon as the loan was out approved, it gets this notification immediately. But for that given person, that given loan has been accepted or auto approved. Then we can stop this. And then if you are a Groovy fan, you can do the same with Groovy language. It will do exactly the same. But the thing here is that we want to scale it. So we just append instances and how many instances we wanted to run. Because by default it starts with single instance. So that will be just one guy sending every two seconds a loan application. But if we started with three instances, it should now send three loan requests every two seconds. And you can see that, yeah. It's popping up with more instances. In exactly the same way, you can scale any of your microservices here. If you need more processing power on the rule service, just start it with dashing instances and the number of instances you like there. For this demo, it's very simple, it's very quick. There's no time consuming activities, neither for rules nor for processes. But to some extent, if you have a long running operation within the process, and long running I mean even two, three seconds, then it's better to increase the number of instances that actually can process your request. Otherwise, the messages will be queued. Your system is not efficient enough, not fast enough. And now you can actually scale it the way you like and scale it individually. You can scale only the process service, or you can scale only the evaluate loan service, or you can scale the clients as we did. It's completely up to you and you can just scale it by starting with dashing instances or starting another instance somewhere else in the network on another machine that will process the messages the same way. Vertex provides us with two options for sending data. It's send, which is point to point, or publish. The send is a nice thing because even though you have multiple instances listening for the same type of data, same components, the vertex will make sure they are distributed in a round robin fashion and delivered to only one endpoint. Publish, and that's publish and subscribe, so sending one will be delivered to everything. And then with that, you can again have different operations and different types of stuff you can actually include in your micro-service and expand them individually. Stop this, as you can see, lots of stuff. And yeah, the request ID is actually here. Groovy loan request. And for different users, different amounts, it is completely generated. I can stop. And the same stuff we have for, if you like, JavaScript. Auto-approved, and of course, if you start doing here, doing the tasks. We have 200, almost 240 tasks already available. It's constantly creating the request and they're being picked up. So you can have this as a UI. You can have another micro-service that will actually provide you with the visualization of your data, of your process, and collect the information again, because here when you click at that, it just shows you the form of the input of the loan application. You can build up another micro-service that actually communicates. So we'll get the information, we'll process that, approve it, reject it, whatever, send it over. And here we have the JS loan request. So every single client has a different, yeah, and this is how it looks like it. A very simple code with my magic stick. So we have the handler that is going to listen for the responses. As soon as you get the response, it will just print it out. And then we have the send periodic. Every two seconds, we run this function. So it's just sending the message that it generates the JSON object. To simplify and to make it polyglot, we use JSON because it's the easiest format to consume in almost any language now, especially those that are supported by Vertex. So we just fill in the data and send it to loan application. And this is just the name. It could be anything. Then the rules are listening to that and waiting for that information. And then just replying after evaluation. And then you can have this. Exact same code in Java. Bit more verbose, but still. That's exact same thing. And groovy, without syntax highlighting. Pretty much it, I believe. And the demo. Yeah. Yeah, and again, you can just scale it by adding instances. And you can scale by adding three here, two there, one there, up to you to define. And based on the requirements. So to sum up, main takeaways from the presentation is knowledge is everything, really it is everything. Once you know what you're going to work with, you know your domain, you can make a wise and fact-based decisions. So think and keep in mind about the what, why, and how. Once you have that, you will be producing way better software for your actual end users. And yeah, those tools that you've seen here, Vertex, Jbpm, Hazelcast, adjust the tools. Today you can use these tools. Tomorrow you can switch them. But the knowledge, once you have that, the tools are just the secondary thing. They will be anyway replaced. That's the technology that's happening. That's happening every single time. And with that, I'd like to thank you very much for your attention and if you have any questions.