Cloud Transformation using webMethods Cloud Container

  1. Introduction:

webMethods Cloud Container offers Lift and Shift capabilities to deploy webMethods Integrations to the Cloud. You can use the same set of tools to develop, debug and test integrations for the cloud as you do for on-premises integration using this offering. fix, patch management and scheduled upgrades, and CI/CD support in the cloud are few highlights for this offering. Existing integration can be deployed to webMethods Cloud Container for Cloud Transformation.

This article explains about the transformation of the on-premises assets (Integration Server, Universal Messaging) to Cloud Container.

  1. Pre-requisites:

  1. Integration Server Assets:

Below catalogue provides the transformation/approach for migrating the on-premises Integration Server assets to webMethods Cloud Container.

 

Asset Type

On-Premise Integration Server

Cloud Transformation with Cloud Container

Comments/Links

Package(s)

Packages on Integration Server

Packages can be deployed from either from Designer or using the CI/CD process.

Access Control List (ACLs)

Associated with the Packages and the assets with in the packages

Can be deployed as individual configurations but is recommended to deploy along with the packages

Adapter Connections & Pooling Notifications

Would be packaged within the Integration Server package

During the deployment to cloud it is recommended to use Variable substitution to replace the values. Providing the values on Cloud Container manually is not recommended. Cloud Container runs on Kubernetes platform managed by Software AG and the values entered manually would be lost if the servers are restarted/upgraded.

Cloud Container is certified with JDBC Adapter, MQ Adapter till now. Certification of remaining adapters are in progress.

webMethods Cloud Configurations

Integration with webMethods.io Integration is driven by WmCloud package

Cloud Container and webMethods.io Integration can interact with each other using Cloud Container connector on webMethods.io Integration. Cloud Container can invoke webMethods.io Integration directly with REST/SOAP endpoints

Addressed by Connector on webMethods.io Integration

Client Certificates

Client certificates generally store the client's public key to user mapping information.

Client certificates should be configured on the platform and can be mapped to users and solutions

CSRF Guard

CSRF guard is applicable only in condition when user is accessing IS admin pages directly

This is provided and handled by Cloud Container UI

  • Not Applicable

Enterprise Gateway Rules

Used for configuring Threat Protection Rules

This is offered by webMethods.io API

External Authorization Server

Integration with JWT, Kerberos, SAML, OAuth, OpenID providers

This is offered by webMethods.io API

Keystores, Truststores

Keystores and Truststores used for SSL interactions

These assets can be deployed to individual solutions packaged within any package

Ports – HTTP(s), FTP(s), Email, WebSocket(s), Enterprise Gateway, Internal

Creating ports are possible with Integration Server/Microservices Runtime

HTTP Ports are cannot be deployed on Cloud Container. Ports are not exposed on Cloud Container. APIs can be accessed through Cloud Container naming conventions.

FTP, Email, WebSocket capabilities are not yet certified on Cloud Container.

Enterprise Gateway capabilities can be leveraged from API Gateway.

Users and Groups

Custom Users, Groups can be associated with Access Control Lists. Authentication/Authorization can be driven by the same

Users and Groups can be deployed as configurations to Cloud Container. But it is recommended to use Access Profiles on Cloud Container for Authentication and Authorization.

Cache Managers

Distributed and Local Caching is supported by Integration Server on on-premise

webMethods Cloud Container does not offer Terracotta Caching for solutioning. Only clustering is supported at this moment.

  • Not Applicable

Clustering

Clustering was manual on on-premises

This is supported out of the box. Both Stateless and Stateful Clustering is supported.

  • Not Applicable

Enhanced XML Parsing

This is enabled on on-premises when Big Memory is enabled

This is not supported as Big Memory is not offered on Cloud Container

  • Not Applicable

Global Variables

Global Configuration framework that can store key, value pairs

It is recommended to deploy the Global variables are configurations.

Hot Deployment, JDBC Pools, Licensing, Logging

These can be configured for on-premises

These are handled and managed by Cloud Container platform

  • Not Applicable

Messaging Configurations

On-premises Integration Server can have webMethods Messaging, JMS configurations with Universal Messaging/webMethods Broker/External Messaging servers

When Solutions are created on Cloud Container with UM as an option platform by default creates the webMethods Messaging and JMS Configurations by default.

However, deploying additional messaging configurations are also supported and the same can connect to external messaging servers.

Metadata, Proxy Servers, Quiesce, Remote Servers

Some of these configurations are required for on-premises

Most of these configurations are managed by Cloud Container Platform

  • Not Applicable

Resource Configurations

Thread Pools, SMTP configurations are the most important configurations

During the cloud transformation these configurations are often ignored but these are one of the important configurations that needs to be deployed. These should be deployed as configurations.

SFTP configurations

Remote SFTP Server and User Alias configurations

These configurations can be deployed as configurations to Cloud Container.

URL Aliases

Used for simplification and masking the actual API end-point.

These configurations are packaged within the custom packages. It is recommended to save these configurations with the same package that the actual API. These configurations would be deployed along with the packages.

  • Deployed with the Package

Web Service End point configurations

SOAP webservice end-point details – both for provider and consumer on Integration Server

These configurations can be deployed as configurations to Cloud Container

  • Deployed as configurations – Similar to SFTP

Extended Settings

One of the important configurations – can be used to change the product behavior or to add custom key-value pairs

These configurations can be deployed as configurations to Cloud Container

  • Deployed as configurations – Similar to SFTP

Custom Libraries

Custom/External libraries are often used to connect to a database using database drivers, implement a custom framework using custom libraries etc.

Custom libraries can be deployed packaged within the custom packages

File Access Controls

File Access Controls are saved within config directory of WmPublic. These are used for CRUD operations on the files.

It is recommended to use external storage while working with Cloud Container. Amazon S3 buckets, Google Cloud Storage, etc. are few examples.

However if there is a need to perform CRUD to use as a transient store, the configurations can be deployed.

4. Universal Messaging Assets:

When Universal Messaging (UM) is used for native webMethods messaging, the required assets on UM would be created by Integration Server connected. Assets needs to be deployed to UM on when it is used as JMS provider. Connection Factories, Queues and Topics fall under this category.

Asset Type

On-Premise Integration Server

Cloud Transformation with Cloud Container

Comments/Links

JNDI Objects

Connection Factories, Queues and Topics

These can be deployed as configurations to Cloud Container

Other Properties

Realm tuning configurations

These can be deployed as configurations templates

  • Same as above.