 Welcome to another OptaPlaner video. This time we'll be looking at this sneak preview of the OptaPlaner workbench. This is still very early development, but I'd just like to give you a taste of what's going on. So, before we actually look at the workbench itself, let's take a quick look of what the workbench is. So, if you look at the key projects, we have three projects. The Drouals rule engine, we have the OptaPlaner optimization engine, and we have the JBPM workflow engine. Now, for both Drouals and for JBPM, we have a workbench which allows you to manage the assets for those, for example, for the rules or for the workflows in a workbench, in a web application, so you can publish them to an execution server. Now, of course, that's a criggle bit missing for OptaPlaner. We don't have an OptaPlaner workbench yet, and this is something we're thinking of building, actually. So, a little bit of information on what the workbench would do. It's basically a web app that allows you to define the domain. So, for example, what you'll be doing today is define a cloud balancing problem, where we have to assign processes to computers, right? And then you can define the score function in there. And once that's done, then this will, the workbench, which is a web app, which is a server, actually, will deploy a Kjar, this is just a jar with some metadata into it, to an execution server. An execution server will then run this solver, run this problem on multiple nodes, right? And in cloud, of course, and it will run multiple solvers on one node, usually the number of threads on there. Of course, we still have to build the execution server, too. But again, we can reuse much of the drills and JBPM plumbing there to speed up the development. And then this exposes a REST service to which you can post your optimization problems and which will solve them then, of course, right? So, let's suppose you have a problem right here. So, here we have a problem where we have two computers and we have five, four processes. We need to decide which process gets assigned to which computer. So, we submit this to the REST service as XML or JSON or whatever, right? We can implement other format types later on, too. And then these get, then the execution server gives you a solution back. And in this case, for example, it tells you that you should put the purple and the yellow one on the first computer and the green and the blue process on the second computer, right? So, and of course, this kind of problem that we are sending towards the execution server should not necessarily be this kind of problem. It could be a nurse rostering problem. It can be a vehicle routing problem. It can be a job-shop scheduling problem. Anything, basically, right at the top of our hand. And of course, the nice thing is, then, if you go back to the workbench, you can start tweaking the score function and so forth. And you can, again, deploy this. And then, of course, the execution server will actually solve according to these new settings, of course, right? And that's basically the iterative development you can do with the workbench and the execution server once it's built, of course, right? So, let's take a look at what we have in the prototype. So, thanks to Walter, Tony and Michael, they quickly built a prototype just to see how and in what direction we can work. So, it's very much a prototype yet. We might not even name it at this point in time, but I can show the basic things at least. So, let's try that. Let's try to create a new project. And let's call it Cloud Balancing 2, because I already created an early one, right? So, Cloud Balancing 2. We can, of course, we don't. So, we can do it like this. Here we go. And we'll give it the group ID is just... Yeah, they must be good, actually. Artifact ID, here we go. Okay, so now we've created a project. Let's take a look at that project. So, here we have it. That's the project. So, in this new project, let's create a new data object. So, first thing we have is we have computers, right? These are part of our problem. So, let's make the data object computer. Here we go. And we are going to add a field here. The first field we're going to add is CPU power. So, every computer has an amount of CPU power, right? So, let's add that. That's a number. You also have some RAM memory, right? So, let's add that too. Here we go. Let's add the network bandwidth. Here we go. And then, of course, let's add the cost, the maintenance cost that we have to pay every month for this computer, right? So, the goal is to, of course, the soft score that we want to goal is to minimize that cost, the number of computers that we use, right? So, this is, by the way, the typical example, the quick start example in the Planner menu. So, like I said, this is the development version. We're still playing with UI. So, what you can see here, we have a computer. We have the CPU power, the memory, the network bandwidth and the costs, nicely, and the roll ends, right? Okay, so let's save this. This is the computer. Computer class, all right. Great. So, let's make another class now. A new class, and let's call this the process class, right? So, we need to decide which process gets assigned to which computer, right? So, okay, we make the process class. Let's add some fields on this. So, it requires required memory, of course. It doesn't really matter in which order we do them, of course, but I'd like to be the assistant here. Then, of course, required memory. So, each process requires some CPU, some memory, and, of course, some bandwidth, right? Network bandwidth. And we'll have to then make sure that some of those, actually, of all the process on one computer is less than the total capacity of that computer, right? Okay, so we have those three fields. Those are pretty normal fields, nothing special there. But, let's just, now, we also need to add one special field, which is the computer, right? And the computer is of type computer, right? So, this is the, basically, this is what Doppler needs to decide for each process, which is the computer for that process. Okay, so, the next thing we need, of course, Doppler needs to know what it can change. So, if we click on the process class, we have to tell Doppler planner that he can play with that class. He can change that class, right? So, we have to tell him this is actually a planning entity. So, we say, okay, this is a planning entity, great. And, of course, once you have a planning entity, and we should refresh again. This is the development version. We can actually look at the computer field, and we can, on the computer field, we can say, okay, this is what changes during planning. So, what we can do here is we can say, this is a planning variable, and we need to add a range, too. So, let's say the computer range here, and that's basically it, and we can save this, right? And, again, I'll refresh just to be sure. So, this is the process class. Great. So, now we have a computer class, and we have a process class, right? Great. So, next thing we need is, of course, a solver configuration, right? So, a solver configuration. Here we go, cloud, balancing, solver, config, right? Let's do this. Let's pick it up and put it in the demo. Let's do it in the demo, too, whatever. And this, here, we can choose the solver configuration. So, what do we need for a solver configuration? Of course, we need to define the score type. So, the default is, of course, hard and soft score. This is what most users use. Then, of course, we'll have to plug in the score DRLs, which you can then, of course, edit here with the guided rule editor, and so forth. And, of course, if you solve by default, then you'll want to set this time net, right? If you're not doing asynchronous solving or anything special like that, you'll just want to set a simple clean time net. So, for example, we could say, let's go for five minutes. And that's basically it. Let's save this. This is a solver config, right? Okay. And this is basically what we have so far for the prototype. I know you have to remember this was written in just a few weeks, so it's not that much yet. But from here, we can go for it, right? So, the next step is that we actually deploy this to an execution server, of course, to the unified execution server. And then, of course, this needs to be built as a KGR first, and then we deploy it. And like I showed earlier, then the idea is that you can send in an XML, so a REST request, and you can send in your problem as an XML and you get back your solution as an XML, of course, right? So, this is just an introduction just to see. Now, if you have any ideas on what else we should add here or if this is a priority to be working on, do let us know. A few of the future things we want to add in this is, first of all, benchmarking support. So, you can actually define a benchmark on the Workbench 2 and let it run in the execution server or in the Workbench itself. So, it can tell you, okay, which algorithms are best to use for your problem, right? And, of course, we'll add many more capabilities, like, of course, integration in the Guided Rule Editor and in the Guided Decision Tables. So, it's easy to select scores and so forth to define if a certain rule is triggers, what the score impact is. So, we'll definitely do lots and lots more once we start working on this, of course, right? Thanks for listening.