In one of my previous Spring Batch blog articles, I wrote about the need to read a set of data, process the data, and export the transformed data into XML for consumption by another system. In this blog, I’ll be doing the opposite. I’ll show you how to read data from an XML format instead.
While working with a client recently, my team was given the task to retrieve the held securities and account data from the system and export it to XML with the goal of importing it into another external system. The solution involved building a Spring Batch job that would read a set held security data, export that to XML data, and deliver the file to the external vendor securely.
In this blog, I’ll be giving a tutorial on how to execute this solution. These requirements form the basis for the example we’ll use.
I was recently tasked with summarizing the data of a several-million-row table, and the task proved to be a bit grueling at first. Eventually, I found a way to summarize the large dataset with Spring Batch, but not without a wrong turn or two at first. In this post, I’ll walk you through my process and how I overcame this …
The last few years have seen a lot of movement to bring applications that don’t require manual intervention from the mainframe to Unix, Linux, Windows servers, or even to the desktop. This concept is commonly known as batch programming, and Spring Batch has been the tool many of us are using to accomplish this. Another trend that is gaining steam is to move from an internally-hosted server to a cloud-hosted system.
In this post, we discuss multiple ways for transferring Spring Batch applications up to the AWS Cloud, including EC2, Docker, Lambda, and others. I concentrate on AWS in this post, but, from my experience in Google Cloud, the same ideas will apply…
Several years ago, 2012 to be precise, I wrote an article on an approach to unit testing Spring Batch Jobs. My editors tell me that I still get new readers of the post every day, so it is time to revisit and update the approach to a more modern standard.
The approach used in the original post was purely testing the individual pieces containing any business logic. Back then, we didn’t have some of the mocking capabilities that we have today, so I went with an approach that made sense at the time.
However, there have been a few improvements in the past several years. One of those improvements has been the ability to Mock beans within a Spring Context. That’s where the @MockBean annotation comes to the rescue.