From the course: Spring: Spring Batch

Batch status control

From the course: Spring: Spring Batch

Start my 1-month free trial

Batch status control

- [Instructor] The batch status assigned to a job or step is important because it is used by the framework to determine if a job succeeded or failed, which ultimately, determines if a job can be restarted. Job flows are not always simple and sometimes we need control over the batch status assigned to a job. To handle this, Spring Batch provides three transitions to stop a job, and override the default batch status. These transition elements are end, fail and stop. By default, the batch status of a job is marked as completed if the exit status of its steps does not return failed and no transitions are specified. When transitions such as on are present, it gets a little bit more complicated. In some scenarios, a step can fail but due to an on transition, the batch status of the job is marked as completed. When we want to alter this behavior, we use one of the stop transitions. If we take a look at our job configuration, you'll see that we have already used the end stop transition. If we were to configure our job to fail, so let's go to the driveToAddressStep and we're going to change our Boolean to true to say we got lost, our job's going to fail but because we have configured our job to use the end stop transition, it's going to be marked as completed. So let's hop over to the terminal and we're going to run our job and we'll see that we'll receive the exception, because we got lost, but when we look at the metadata stored regarding the job, we'll see that the batch status is successful. So there we see our stack trace. Now if we head over to the database and we look in the job repository, and if we look at our batch job execution, we're going to see that it was complete and then when we look at the step executions, you'll see that our driveToAddressStep was abandoned. So that's not what we want to happen. In this case, we would never be able to deliver our package. So let's go ahead and clear the metadata within the job repository and I'm just doing that by dropping the tables. And we'll navigate back to our job configuration. That last status was not ideal so let's take a look at another status named stop. Stop is going to allow us to pause the job and then we can fix whatever the problem is and rerun it at a later time. So what we'll do is here where we are failing, instead of executing our storePackageStep, we've going to replace that with a call to the stop method. And in this case, we're just going to pause the job and allow for it to be manually fixed by a batch job operator and then we can rerun it. So let's go back to our console and we're going to clear it and then rerun our job. This time, the job is going to pause. So we'll see the exception thrown. There's our exception but you'll notice that it's in the stopped status. That's going to allow us to go back and we'll just head into our class and we're going to go to the driveToAddressStep and we're just going to manually fix the job. Typically this would be changing some data or figuring out what the problem was and resolving it. In our case, we're just going to flip our Boolean so that we can successfully execute the job. So here I'll clear our terminal and then we're going to go ahead and run the job again. You'll notice this time, we're able to actually restart the job and it can successfully process. Okay. So there we were able to successfully complete the driveToAddressStep and then we went through the remaining flow of the job. Now, we're going to take a look at an additional status that we can use and that's the failed status. So let's navigate back to our job configuration. I'm going to flip over to fail the job. We're going to get lost. And then if we navigate to the configuration of the job, instead of stopping, we're just going to go ahead and fail. And now, we'll need to first clear out our metadata so I'm just going to drop all the tables again. This is just for demonstration purposes and then I'm going to clear our console. And we'll rerun the job. This time, we'll notice that we will get lost. We'll throw the exception but the job will fail, which is much better than being marked as completed. We're explicitly marking the job as failed. So there you see that the status of the job is failed. We can take a look at that within our database if we want to query the different executions and their statuses. So here we can see that our driveToAddressStep did fail and if we take a look at the status for the job execution, it's failed as well. Now, with that, we can go ahead and within our application, we can resolve the problem. So let's go back and we're going to mark our Boolean as false. That's going to allow the job to succeed and if we navigate back to the terminal, you'll notice that we're able to rerun the job this time because we're in a failed status and the job will succeed. So using the different stop transitions, and the corresponding methods in the Java configuration, we're able to get better control over the batch status of our job. And that's important because these transitions can put our job in a state that allows us to rerun it. We need to be extra careful when we're using the on transition that we don't place a job into a state because of it's batch status that will not allow us to recover from an error.

Contents