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.
This article will set up a basic Spring Boot app that incorporates Apache Camel to move some sample files around.
If you are like me, you find that flat-file processing can be pretty dry. Considering what Apache Camel does, its name is very fitting. While there are plenty of reasons for the name, it definitely makes sense that Apache Camel does a lot of lugging things around for you…
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.
The big three cloud providers (AWS, Azure, and Google Cloud, in that order) have their various strengths and areas of expertise. Most large organizations though typically pick one cloud provider for their cloud computing needs. This works well if you’re a Java shop that’s on AWS, or a Microsoft shop on Azure. But what if you’re on a large Java project in an organization that wants to use Azure? You’re in luck.
Microsoft Azure has come a long way, and is very supportive of non-Microsoft technologies. The proof though is in the pudding. Which is where this blog post comes in. I take Josh Long’s Bootiful Microservice Services, a great starting point to get a cloud native Spring microservice application up and running, and show how it can be run on Azure.
This first blog post will be all about setting up our basic microservices by walking through the various parts of Josh’s example application, with some best practices and patterns that I’ve found to be effective. Rather than a simplistic ToDo application, we’ll be basing our application off of my favorite bagel shop in New York, Original Bagel Boss in Hicksville, to manage its orders, inventory, etc. If we can run a bagel shop on a Spring application running on Azure, and keep customers happy and full of carbohydrates, then it proves out for applications of a similar size and complexity.
We’ll be staying mostly inside the familiar Java confines, then slowly start working our way out to getting our application deployed to Azure. Then we’ll start introducing additional complexity like Spring Batch jobs, a React front end, etc. A setup this complex will show that Azure is ready for prime time when it comes to running applications in production, even if they are built on non-Microsoft technologies…