​SAP is the backbone of thousands of companies worldwide: its end-to-end suite of applications and services enables business and public customers across 25 industries globally to operate.

Enterprise resource planning is one of the strongest areas covered by SAP to take all the core processes needed to run a company – finance, HR, manufacturing, supply chain – and integrate them into a single system.
​
Companies though are complex ecosystems that need to interconnect IT and business processes, while reducing their need for human intervention.

Automate anything, Run Anywhere is our motto! 

What better place to start making it real than from our very own Workload Automation test environment? 

​We have been applying it in our Test Lab for Workload Automation version 9.5 since its general availability in 2019, and to all the subsequent fix packs, including the last one, fix pack 3.  ​

To improve productivity and to save IT management costs and time, our customers are starting to move to the cloud environment and are moving heavy workloads from a set of on-premises machines to a resilient cloud infrastructure. 
So, our principal mission is to facilitate, secure, and support moving a workload automation deployment, from an on-premises infrastructure (minimum WA 95 FP3 version required) to any cloud infrastructure where Workload Automation (WA) is already supported.​

​A question which everyone would have in mind while Upgrading to WA 9.5 is to manage all the Carryforwards that are present in old Production Plan on the older Version of the Master and to migrate them to the newer Master Server . This Blog aims to sort this problem once and for all to ensure seamless transition to IWS 9.5 without any hassles. ​

Let us begin with understanding of Azure what it is all about before moving to our Azure Resource Manager plugin and how it benefits our workload automation users. ​

​As human beings, we have always been fascinated by the unknown, and we need to understand it, interpret it, and draw results from it. Today, however, living in an increasingly hyper-technological, interconnected world, where we collect billions and billions of information and data, we have difficulty because our ability to acquire data exceeds our ability to give meaning to it.  

Zowe and its major components Web UI, API Mediation Layer, and CLI, are likely to become the new interface for the next generation of mainframers.

The Zowe framework is the bridge that connects modern applications with the mainframe by providing easier interoperability and scalability among products and solutions offered by multiple vendors. 

Let us understand first about AWS Simple Queue Service (SQS), how Amazon SQS works, it is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. ​

Before moving into Blue Prism plugin, let us understand what it is all and how it is benefits our workload automation users.
 
Note: Blue Prism is an experimental plugin in our Automation Hub and it may support limited features.
​

​Amazon Simple Notification Service (SNS) is a managed service that provides message delivery from publishers to subscribers (also known as producers and consumers). Publishers communicate asynchronously with subscribers by sending messages to a topic, which is a logical access point and communication channel. Clients can subscribe to the SNS topic and receive published messages using a supported protocol, such as Amazon SQS, AWS Lambda, HTTP, email, mobile push notifications, and mobile text messages.