In the last segment, we covered what happens when a request is rejected and sent back to the submitter. Let's take a look at the process and focus on 'send confirmation email service activity'. So this is a service task, which means that the system is going to be executing that. In this case, we're just going to send an email to the person. Now, you can launch that particular activity. First of all, notice that the commander best practice of task underscore followed by the activity name is what we set for you automatically. And when you open the service task behavior, you can see that it is created on the request vacation business object, a send confirmation email behavior. Think about a behavior as a method or a function that's a part of the request vacation object and in this one is a server only. There are other types of behaviors like various H2 B operations, and it passes in the instance of request vacation as well as the external task information. For those that know Camunda, this is the external task pattern. Now automatically all of the connections to the server the long polling to get the external tasks that's all handled for you automatically. And the only thing that you have to implement is the body of what happens when that external task comes to this service. So there's not a real implementation in here. Basically, the external task handler calls this function when there's a task to process. And we have a couple of debug statements in here. This is where you would put your logic in the middle. You'd put in logic to prepare and send the email using any number of NPM packages and chunks of logic.
A couple of other highlights. This is an async function so you can use await in your calls. Your code stays nice and clean. You can do things like a weight get template, a weight fill in template or weight send email so it keeps your code nice and clean. And if you throw an error in this, the external task handler will automatically register an incident on the process instance. So you don't need to be too careful about error handling here. You can just let it throw the error and the external task handler will catch it and put the right error into B into the command engine. So at the core of it, we actually will make a change request vacation, that status is notified and then we'll debug that out. We don't need to do any save operations or anything else like that because also the external task handler takes what's been done in the request vacation and saves that into the database and then automatically updates all the any of the process variables that are exposed. For example, status is an exposed variable in this particular case. So let's see this in action here. We've got a task list where there is a request that I've queued up for me to review. And I'm just going to it's too hot in Florida now and I'm going to reject this or approve this. I don't want to say that and submit. Now, you notice this time we have a second tab. This tab is the design of the app. This is the actual running app.
This is what we call an app manager. An app manager is where it's dynamically rebuilding code, starting and stopping the server. And for this one, looking at the logs and this application is running, we can see in here the debug entries in the vacation request, sample app request, vacation business object, send confirmation email so you can see here is the object for the request vacation. Here's the external task information that came from Camunda. And finally here is the status being set to notified. So you can do anything that you want inside of this, including accessing methods of other business objects in your design, making HDB calls, using any kind of Node.js package to connect things like Box or to Stripe or whatever the case might be. So now you're basically just back into Node.js Island writing a small snippet of server side logic that will run as a part of your application. So that is how we handle service tasks. And in the next segments we will take a look at some administrative tools for managing processes.