A Step-by-Step Guide for Deploying IBM Sterling Order Management on AWS

Consumer behavior has changed in recent months with shoppers embracing an omnichannel retail experience like never before. More and more customers are buying online and picking up their order in the store, while many others are buying online and want the flexibility to return items at any store location. You can offer your customers a seamless omnichannel experience with the IBM® Sterling Order Management System (OMS). In this blog post, we’ll give you step-by-step instructions and best practices to deploy the application in your AWS environment.

More Flexibility with Modern Architecture

The Sterling OMS solution allows you to orchestrate an end-to-end omnichannel fulfillment network using powerful core capabilities and next-level options that combine multichannel order aggregation, inventory and delivery visibility, and service availability, all within a single platform.

IBM re-architected its Sterling OMS platform to make it simpler and more flexible so business users have more control over order operations with self-service capabilities—without going to IT for every change. Users can implement new delivery choices, such as buy online, pick-up in store (BOPIS); ship from store; drop ship; return anywhere, and more. It also equips in-store sales associates to handle customer requests, such as finding items at other locations (save-the-sale); line busting during peak periods; and assisting store managers with omnichannel processes. Because you can deliver fulfillment services more quickly, you can enhance the customer experience to bolster your brand.

Built on a modern architecture, the solution wraps Docker containers around order management business services. This architecture streamlines application management and the release of new functionality. The container technology also supports varying levels of technical acumen, business continuity, security, and compliance. All of this translates into faster time-to-value and lower IT costs. If you want to reduce capital and operational expenditures, speed time to market, and improve scalability, elasticity, security, and compliance, you should consider moving your on-premises IBM Sterling application to AWS.

Benefits of Red Hat^® OpenShift^® Container Platform

With release 10.0, IBM introduced container-based technologies using curated deployment patterns via helm charts and related tooling. The solution is certified on the Red Hat OpenShift Container platform, follows best practices, and provides an integrated support model to help resolve order management software issues. OpenShift helps you manage the lifecycle of developing, deploying, and managing container-based applications.

IBM Sterling OMS certified containers (enterprise and professional editions) bring together Red Hat-certified order-management containers, IBM-certified production-grade helm order-management charts and streamlined deployment instructions for OpenShift.

Configuration Guidelines

If you’re ready to configure IBM Sterling OMS on OpenShift on AWS, we’ll give you step-by-step instructions to integrate with the database and JMS server; customize the deployment to your needs; and deploy the application, agents, and integration servers with auto-scalable containers geared toward production deployments.

The certified containers edition provides the following:

• Order management containers (certified by Red Hat and IBM) with images built using open source technologies, such as UBI and buildah.
• IBM-certified helm charts for enterprise-grade, secure, production editions.
• A developer environment with open-sourced IBM DB2 and IBM MQ containers designed to be integrated with an order-management app server and agent containers.
• Scripts and documentation for creating builder images and customized build pipelines aligned with the OpenShift Source-To-Image (S2I) framework.
• Container scaling recipes to automatically scale up and scale down your containers in real time based on pods, CPU, and memory limits.
• Liveness and readiness probes that work with replicas to monitor the health of the application and provide graceful self-healing recovery characteristics.
• Unified monitoring, security, and logging tools to give administrators a consistent hybrid cloud interaction model.

We’ll assume that you have reviewed the product documentation and you are aware of the prerequisites and system version requirements. We’ll also assume you have installed the following:

• Red Hat OpenShift version 4.4 or above
• IBM Db2 database V11.x or higher OR Oracle database v19c
• IBM MQ JMS server V9.x or higher OR WebLogic JMS
• Sterling Order Management certified containers V10
• Helm v3.x (inbuilt in OpenShift)

Order Management Containers and Helm Charts

To enable a modular deployment of Sterling OMS-certified containers, the software distribution provides three images for x86-based architecture:

• om-app — Order management application server image handling synchronous traffic patterns embedded with IBM WebSphere® Liberty application server
• om-agent — Order management workflow agent and integration server container to handle asynchronous traffic patterns
• om-base — Image provisioned for adding your extensions/customizations to the base product and enabled to rebuild the preceding images

These images are enabled for integration with IBM DB2 and MQ applications with the required versions of the client jars.

The Red Hat OpenShift Developer Catalog has helm charts for OpenShift 4.4 and can perform some of the following key actions for deploying the application and agent containers:

• Create deployment of the application server with one replica
• Create health monitor deployment
• Create user-defined agent and integration servers
• Create job for loading factory setup data
• Create service for accessing the application server via routes
• Create configuration maps for application server-specific settings and user-defined MQ bindings
• Upgrade to specific Fix Packs
• Configure network policy to limit the type of traffic to pods

For a complete set of helm chart capabilities, refer to README. The charts are readily available in the OpenShift developer catalog, and you can edit the values.yaml based on your deployment patterns. The following landing screen shows the helm charts in OpenShift:

The following architecture diagram displays the grouping of application server and agent server pods within the OpenShift cluster with the DB2 database and IBM MQ server. OpenShift routes handle the external traffic into the application server pods. Upon customization, the base container can regenerate customized om-app and om-agent, which can be pushed to the OpenShift container registry using S2I CI/CD. Application load balancers through request routing manage traffic to the OpenShift Platform and JMS.

Create a Developer Environment

For successful agile development, you must have instant access to a pre-configured working environment on your workspace/computer. Access to databases, messaging servers, and application binaries is much easier with containers. You will typically perform the following steps on your local computer to start customizing and configuring the order management application:

• Install Docker and/or podman utility for loading the containers.
• Download the Db2 development container using Docker pull ibmcom/db2 and configure the application using the instructions provided at ibmcom/db2 to bring up a Db2 database server.
• Download the MQ development container using Docker pull ibmcom/mq and configure the application using the instructions provided at ibmcom/mq to bring up an IBM MQ messaging server.
• Load the order management application using Docker or podman:

docker run -e LICENSE=accept --privileged -v <shared file   system directory path>:/opt/ssfs/shared -it --name  <container name> <image>

podman run -e LICENSE=accept --privileged -v <shared file   system directory path>:/opt/ssfs/shared -it --name  <container name> <image>

Once the container is loaded, you need to get inside the container to enable database credentials for connectivity; load out-of-the-box factory setup data; create Javadocs for information on order management APIs; build and deploy the database, code, templates, user exit, and service customizations; and create custom images for your app and agent containers. In the product documentation, you can find additional details to customize your environment and log customizations for extracting logs based on the pods in the product documentation.

Upon building the customized images, you can deploy them in the OpenShift environment as defined in the product documentation. Alternatively, you can run the customized containers on your laptop using the Docker or podman commands above before deploying in a development/QA environment in the OpenShift container platform.

Creating a CI/CD Pipeline

With the customizations validated in a developer environment and checked into a source GitHub repository, you can establish an automated CI/CD pipeline. OpenShift provides the following strategies and can be read in detail:

• Source to Image (S2I)
• Pipeline
• Docker
• Custom (recommended approach for Sterling OMS)

The custom build strategy integrates your GitHub repository with the om-base image so any source code update triggers the build configuration to generate customized images that can be deployed in your dev/QA/staging/production environments. The product documentation includes a sample build config YAML to configure your credentials with the om-base image stream.

You can streamline weekly or monthly releases by automating your customization and build pipeline, so you can shift staff to other projects.

Configurations Required for Deploying in OpenShift

The OpenShift documentation details the infrastructure requirements to deploy Sterling OMS in AWS. If you have questions, please contact Technical Sales Support for information on sizing the application, agents, and integration servers in a certified container model. AWS offers a wide variety of instance types for running IBM MQ and IBM DB2. Please refer to this guide for available instance types.

Here are the minimum software configurations to deploy order management containers in OpenShift:

• Secrets — Creates sensitive information like passwords
• Security constraints — Specific constraints enforced by customizations
• ConfigMaps — Capture Liberty server customizations, application/agent’s customer overrides, log4j customization, and database connectivity
• Persistent volumes — Mountable file drives for referencing any external files like SearchIndex and log folders
• Ingress/Routes — Ability to push/pull images into OpenShift registry and to expose application server URLs for external access
• Newer fix packs — If necessary, review and install any unapplied fix packs not included in the image

The product documentation provides additional instructions and YAML files to configure Sterling OMS. You can configure various projects across various environments.

Application Self-healing

A robust application is designed to detect signs of failure and programmed to take corrective action. In an enterprise-grade implementation like Sterling OMS, even with containers, failures could occur in a variety of situations, such as:

• Container crashes for any specific/unforeseen reason.
• Supporting applications, such as Db2 or MQ, become unreachable.
• Unscheduled/planned maintenance.

The Sterling OMS application and workflow agent containers are equipped with the following capabilities that enable the application to recover gracefully or spin up additional instances:

• Multiple replicas — Sterling OMS provides one replica out of the box. In your production instances, we recommend you have two or three replicas per deployment. If an entire pod goes down, the replicas in other pods can continue to service your requests.
• Liveness probe — This probe runs during startup and validates successful invocation of the container and also periodically revalidates server state and health. If there’s no signal for a given duration, the container automatically restarts.
• Readiness probe — This probe ensures that the containers are ready to receive requests. For the application server instance, this probe validates whether the Sterling OMS application login page is reachable and checks for active heartbeat confirmation records inserted in the database.

Application Automatic Scaling

Once the images work in your QA and development cycles, the images are ready to be consumed in a staging or pre-production environment, before the final push to production. In pre-production environments, we recommend you perform production-like load tests to validate the performance, scalability, and availability of the application.

OpenShift provides recommended installation and host practices performed by a cluster administrator for scaling and performance of the pods. More information is available on these techniques. You can automatically scale Sterling OMS by using the Horizontal Pod Autoscaler, a Kubernetes feature from OpenShift. Currently, OpenShift allows auto-scalability based on CPU utilization and memory utilization (beta). For Sterling OMS, we recommend enabling automatic scalability based on CPU and that you configure memory-based management according to the deployment’s min and max limits. Moreover, we’ve found that it’s more efficient to add pods based on CPU rather than based on memory utilization. This approach keeps the container footprint small.

You can scale the agents, integration servers, and application servers by specifying the following oc command:

oc autoscale deployment <deployment name> --min=1 --max=2 --cpu-percent=80 -n <namespace>

Example 1:
oc autoscale deployment oms-svt-app-srvr1 --min=2 --max=6 --cpu-percent=70 -n oms-svt

Example 2:
oc autoscale deployment oms-svt-scheduleorder --min=1 --max=4 --cpu-percent=80 -n oms-svt
When autoscaler kicks in an event is generated in the dashboard that shows the increase in replica:

Generated from deployment-controller
Scaled up replica set oms-svt-scheduleorder-agent-5669db7f49 to 3

In the preceding examples, both the order management application server and agent server are automatically scaled with a minimum instance when starting up those containers and can scale up to a maximum ceiling of six and four containers, respectively, when each of the container’s CPU utilization increases past the desired percentage threshold.

Keep in mind that you must test this setting internally with your customized image to identify the resource usage. Do not confuse HPA with the resource requests and limits set at the individual deployment level, as the latter is defined to ensure the pod can be started on a node within the request and within limits.

IBM DB2 and IBM MQ Deployment on AWS

You can create highly available DB2 instances by replicating the primary instance in AZ1 to the standby instance in AZ2 using IBM High Availability Disaster Recovery (HADR) replication. If the primary node becomes unavailable, TSAMP fails over to the standby instance. DB2 applications automatically reconnect to the standby instance using the IBM Automatic Client Reroute (ACR) feature.

For the IBM MQ server, you should mount the Amazon Elastic File System (Amazon EFS) on the IBM MQ server instance for distributed storage, to ensure high availability of the queue manager service and the message data. If the IBM MQ server fails in one Availability Zone, a new server is created in the second Availability Zone and connected to the existing data so no persistent messages are lost.

New Container Releases

IBM Sterling OMS containers are released every quarter, and the What’s New and What’s Changed sections will provide details on the latest changes. In the upcoming OpenShift 4.6 version helm catalog, you will find a UI-driven approach for deploying the OMS charts.

—

We hope this detailed information helps you successfully deploy IBM Sterling OMS in AWS. Contact your AWS account team today to get started.

Guest co-authors

Lokesh Murthy has been part of the IBM Sterling Order Management System for more than ten years. He has worked on all the technologies of Sterling OMS, including UI, Backend, and DevOps. He has been instrumental in adding several features to the Sterling OMS while also helping customers with their critical issues. Lately, he is actively involved in the container strategy for OMS and has worked towards designing and developing customer-focused tools for simplifying processes from development of OMS customizations to deployment of customized images.

Vijaya Bashyam started her career in Sterling Commerce before joining IBM. Early in her career, she established herself as a performance expert and has been instrumental in enabling some of the world’s largest retailers to scale Sterling’s Order Management System (OMS). She is a recognized, often-sought leader by customers and partners for guidance on key performance challenges as retail customers expand to exponentially increasing commerce workloads. More recently, Viji expanded her role to the design and architecture of OMS containers supporting AI applications and IBM’s hybrid cloud strategy, driving critical business applications and workloads running on OpenShift’s enterprise Kubernetes platform to a cloud-native experience anywhere.