Introduction 

This article will demonstrate how to configure the connections and sync the assets to Integration runtimes. 

Pre-requisites 

• A webMethods.io Integration tenant. 

• Administrator access to the webMethods.io Integration platform  to perform 

• • create edge runtimes 

• •  version control configured  

Audience 

This article is intended for Integration architects and developers working with  webMethods.  

Use case 

The client has migrated assets from their self-hosted setup to the cloud platform. Their development team now aims to orchestrate and configure Deploy Anywhere connections to support their business use case. 

Existing setup 

To be Setup 

Create EdgeRuntime 

METHOD: POST 

URL: https://<TenanName>/apis/v1/rest/control-plane/runtimes 

Request 

 { 

"name": "cardissuanceazureruntime", 

"description": "cardissuanceazureruntime", 

"visibility":"private" 

} 

 Create Instance 

METHOD: POST 

URL: https://<TenanatName>/apis/v1/rest/control-plane/runtimes/<EdgeRunTimeName>/instances/new-pairing-request

 Enable/disable the Edge runtime  

METHOD: POST 

URL: https://<TenantName>/apis/v1/rest/control-plane/runtimes/<RuntimeName>/enable

Orchestrate the flow: We need a project to host our flow service. In this case, we’ve created a new VCS project named 'LogisticArtefact' 

Folder structure of webMethods project 

• Each project includes a scaffolding .yml file that defines its packages, configurations, and other relevant details 

Structure of Scaffolding file when External VCS project is empty 

Structure of Scaffolding when External VCS project contains the custom packages and other dependent services 

•  In our setup, we use package services that publish events to the Kafka system. 

• We have added the jars on our webMethods project “LogisticArtefacts” which are required to enable run the Kafka connector. 

Few reference links:  

Tech Bytes Articles 

• How to setup the version control and create the project in webMethods.io Integration 

• Push the assets to the external repository and pull them on the webMethods.io Intgration cloud platform  

Tech Bytes video link 

• Import Assets from external repository

• Push Self hosted assets to external repository and pull them on webMethods.io Integration

 Develop Flow Service 

• Create the flow service and in our case, I have named it as “OrchestrateFlow” 

•  Select the package service and then select the service to be invoked. 

Note: 

• When using cloud design time, asset syncing isn’t required. However, for edge runtime or cloud runtime (CRT), assets must be synced 

• When assets are synced, only components like package services, global variables, connectors, etc., are transferred to the target runtime. 

• Still, we need to sync the connector after configuring the credentials. 

• Before syncing assets to the ERT, ensure they are committed to the external repository. By default, assets are only saved, not committed. 

• In my case i have DAF service developed with in the same project. Therefore, when i click sync all the assets will get sync to the ERT along with jars. 

• If the DAF service is unavailable, only the package explicitly selected for sync will be pushed to the ERT. Other project assets will not be transferred. 

Configure the connection 

• All connectors used in external packages are listed under the Deploy Anywhere tab. 

• Before syncing metadata to the runtimes—ERT in our case—credentials must be reconfigured. 

• Now that the flow is orchestrated, connectors are configured, and assets are synced, let’s review the details available in the applied manifest file for the Edge Runtime (ERT) 

Applied manifest file for ERT 

• Manifest file provides the details for ERT what we have added once the ERT comes up and start running. 

• Manifest file contains the multiple section 

Packages : Custom Packages Deployed on ERT 

• LogisticArtefactsProject 
  Purpose: Developed specifically for your use case.
• CustomServices 

          Purpose: Also tailored for your use case. 

• WmKafkaAdapter 
  Purpose: A default package pulled from WpmRegistry to support the above two custom packages. 

 Configurations:  

• The Configuration section outlines the property values that were modified and synced to the Edge Runtime (ERT). 
  In our use case, we updated the JaasConfig, and its details are reflected in the manifest. 

• This section not only captures connector configurations but also indicates the state of each connector (e.g., Enabled or Disabled) at the time the diagnostic file was downloaded, and the manifest was verified. 

Testing: 

We are now submitting events to the Kafka system using the orchestrated flow developed in the previous steps.