Moving from Oracle ATG to Microservices-Based Commerce

Using a single platform hosted from an on-premise server was once a great way to do business. These days, there are better ways to work. A microservices-based architecture uses scalable, reusable components so you can adapt quickly to the changing online world.

Oracle ATG is a server-side, component-driven platform that allows you to use headless systems while retaining most of its features. So if you already have an Oracle ATG setup, you can keep the frontend and migrate the backend to a microservices-based alternative for more flexibility. 

In this post, we’ll talk about the advantages of microservices-based commerce and how it can help grow your business. If you’re moving from Oracle ATG and want to learn how and why to make the switch to microservices, I’ll explain what you need to know and show you some simple examples of how you can migrate your data.

Note: We’ve written before about migrating away from classic e-commerce monoliths like Salesforce Demandware. As you’ll see, many of the same concepts apply to Oracle ATG.

Why Microservices?

Oracle ATG is excellent in many ways but has limitations. Moving away from it completely or partially can avoid those problems. Let’s look at some of the areas microservices can improve. 

Security

• When security issues arise, a fixed system like Oracle ATG can leave you stuck because you need to wait for a patch and then update the whole system.
• Microservices allow the building blocks of your system to be regularly updated, individually dealt with, and even replaced or temporarily taken offline.
• Due to microservices’ modular nature, you can tune everything to your needs and update specific elements at any time.

Technical limitations

• Oracle ATG’s old technology compels developers to understand not only Java but also ATG’s Nucleus framework. Finding and retaining these highly specialized developers who can update your system adds another barrier.
• Working with dated technologies like Java Server Pages is slower and more challenging than more recent alternatives. Critical features like dynamic pricing, advanced search, and cross-channel real-time inventory availability are hard or impossible to implement in Oracle ATG.

Flexibility

• With a headless system, your backend and frontend are not tightly coupled. You can add different frontends for different platforms and delivery channels that don’t need to be updated every time you change the backend.

Replacing Oracle ATG

Online platforms offer so many features that it can be hard to know where to begin rebuilding. Let’s talk about the core features that should be your priority.

Step 1: Decide where to start the migration

Let’s look at some of Oracle ATG’s services and decide what to implement using microservices. 

Product information management (PIM)

Storing product information is a crucial part of most online stores, as many businesses hold vast data. Thus, transferring this to a new system accurately and automatically is an essential first step.

With a microservices-based backend, this data is available across the whole set of services you offer, and once it’s there, it won’t need to be reformatted or reentered for new systems.

Because this is such a crucial step, it’s imperative that you correctly do so. fabric can help with its own PIM system, ensuring this critical step goes smoothly.

Order management system (OMS)

You won’t sell much if the customer can’t make orders, so along with your product data, a new order management system should be near the top of your to-do list.

It needs to handle all potential transactions a customer can make while placing an order, collecting payment details, and passing them to your payment handler. It needs to check if stock is available, update it, and let your warehouse know what to deliver. You’ll also want to store customer information so users can track what they ordered.

Getting this right is essential and shows customers they can trust your site with their information. Mistakes can put people off ordering entirely, and that costs you money.

Building this system with microservices means you can perfect everything and use the backend to support a range of frontend services. You can focus on the presentation and deliver the best user experience possible.

fabric has a prebuilt OMS system that can save you the trouble of building it yourself. See if it does everything you need, and compare the cost to set everything up yourself.

Other supporting services

Aside from those already mentioned, Oracle ATG has many features that you’ll also need to replicate. Some you might not want; not copying those can improve your new system’s agility and manageability.

The core services of Oracle ATG include ID generators, scheduling, and random number generation, which may be helpful but also showcase its monolithic nature. Take advantage of the opportunity to examine what Oracle ATG does and replicate what you need most.

Step 2: Build a middle layer

When moving services away from Oracle, you can use the API gateway pattern to route calls to your new backend replacements. That way, you can sidestep Oracle’s backend architecture while continuing to use its frontend features.

With your gateway in place, you can focus on building new services one at a time, which allows you to effectively “swap out” legacy services. The gateway can send some calls to Oracle ATG and some to your new system, simplifying things so you can monitor the effects of your changes.

It also means you can revert to your old setup if needed. Just replace your new routing calls with the old ones in the gateway or service mesh.

Step 3: Migrate data from Oracle ATG to microservices

If you have an existing Oracle ATG setup, it probably has a large amount of data that you need to transport to your new system. One way to do this is to export it from Oracle to an XLS or CSV file. Another is to export everything in the database to an XML file.

Exporting data from Oracle ATG

Oracle ATG includes a huge number of services in its API. When rolling your setup, you will want to replicate some but not all of this functionality. As well as having a more streamlined, focused set of services, you can also add API features that precisely do what you want.

To get data out of Oracle ATG and into your new system, you’ll need to look carefully at how it is stored and see whether you want to replicate or change existing data structures. If the system transfers data from one property to another, you’ll need to decide whether to make changes and how.

The following table lists properties used to store product data, sorted by how each property is set:

For more details, check this documentation.

Importing data into microservices

After exporting, you can use JavaScript to pipe the data into your new microservices. We’ll walk you through an example of how to do that in AWS.

Amazon can copy the data from your old database to the new services using TypeScript and SQS. Have a look at the documentation for more details. Here’s an example of how you can adapt that code. Only a few fields are included:

const { SQSClient, SendMessageCommand } = require("@aws-sdk/client-sqs");
const REGION = "us-west-1"; //replace with your region
const params = {
DelaySeconds: 12,
 MessageAttributes: { // adjust this to your data if different
 id: {
 DataType: "Number",
 StringValue: "543",
 },
 displayName: {
 DataType: "String",
 StringValue: "Pure Cotton Regular Fit Shirt",
 },
 manufacturer: {
 DataType: "String",
 StringValue: "Mark’s Shirts",
 },
 version: {
 DataType: "Number",
 StringValue: "3",
 },
 },
 MessageBody:
 "Clothing Store Product Data.",
 QueueUrl: "SQS_QUEUE_URL", //replace this with your queue URL
}
const sqs = new SQSClient({ region: REGION});
const run = async () => {
 try {
 const data = await sqs.send(new SendMessageCommand(params));
 console.log("Success, product sent. MessageID:", data.MessageId);
 } catch (err) {
 console.log("Error", err);
 }
};
run();

Test and repeat

Taking the transition one step at a time allows you to take stock and ensure no bugs have crept in. The best way to avoid hiccups is by testing everything and making sure your changes correctly work before moving on to the next service.

If you repeat this process, you can migrate the elements of your setup one by one while minimizing disruption. Remember, doing too much at once can make it hard to track bugs and fix problems.

Conclusion

A microservices-based approach will leave you better equipped to compete in online commerce. The increased flexibility and modular nature let you expand and improve at your own pace.

Of course, doing everything yourself gives you complete control, but it can be expensive and time-consuming. You can quickly and easily add a prebuilt solution for some or all of your microservice infrastructure; it’s worth considering.

fabric lets you build headless microservices that support all kinds of delivery channels. Get in touch to see if we can support the changes you make to reap the benefits of modernized technology.

James Konik

Tech advocate and writer @ fabric.