On the Deploy screen select to Create runtime and call the new runtime customer-ir.

Also, on this runtime, set it to be single replica to save on resources. Continue through the wizard, and when prompted, add configurations, then leave the ones already selected, but also add in default-switch-server-privatenetworkagent. This will enable the runtime’s callable flows to be called by any other runtime associated with the webMethods Hybrid Integration instance you are using.

Finally, select Deploy at end of the wizard. You will then have created the first part of your coffee shop integration which is running on a webMethods Hybrid Integration managed runtime associated to your provisioned instance.

Setting the system up:

Creating a self managed runtime using App Connect Enterprise software.

The second part of the setup is to create (or reuse) a remote running App Connect Enterprise runtime.

There are several supported ways to connect a remote App Connect Enterprise runtime. If the remote runtime is already running, and publicly addressable, it is possible to set up webMethods Hybrid Integration to connect directly. This can be done whatever the form factor is of the remote App Connect software - it can be an existing ACEaaS instance, an ACEcc system or an on premises install of the ACE software. See Managing remote runtimes for full details.

As well as these direct mechanisms, it is possible to connect remote runtimes using the App Connect Switch mechanism. This has several major advantages:

• The App Connect runtime connects out to the webMethods Hybrid Integration managed switch so does not have to expose any administration APIs on the public internet.
• It allows the remote runtime to provide access to their callable flows, and to call other callable flows in the webMethods Hybrid Integration instance.
• It is very simple to setup in a secure way without any complex networking required on the ACE runtime system.

We will use the switch mechanism to attach the remote runtime for this article.

You need App Connect Enterprise software (ACE) installation at version 13.0.3.1 or later installed locally. You can download IBM App Connect Enterprise Evaluation Edition and set that up on any machine that you own such as your laptop.

Once you have the ACE install you need to create a standalone Integration Server to use as the remote runtime or you can use an existing one if you already have one setup.

If you don't have an Integration Server, create one by completing the following steps:

1. Open the App Connect Enterprise command environment.
• On Windows, open the Start menu and click IBM App Connect Enterprise Console x.x.x.x.
• On Linux, locate and source the mqsiprofile script in the directory where you installed App Connect Enterprise (source install_dir/server/bin/mqsiprofile).
2. Run the mqsicreateworkdir command and specify the full path to the directory that you want to.
3. Create (mqsicreateworkdir c:\intServerName). For more information, see mqsicreateworkdir command in the App Connect Enterprise documentation.

Now you have an ACE Integration Server on your local system you can configure it to be available in webMethods Hybrid Integration. Follow the steps:

1. In the navigation panel of App Connect, expand Connect, then click Private networks.
2. Click Create to create a private network agent.
3. Change the default name to something more meaningful, then click Create.
4. Open the Actions menu for the new private network agent and click View setup instructions.
5. On the Remote administration tab, expand step 2 and click Download the configuration.
6. The switchclient.json file is saved to your default download location.
7. Move the downloaded switchclient.json file to the config/switch folder in the work directory of your App Connect Enterprise integration server. If the switch folder doesn't exist, create it.
8. Start the App Connect Enterprise integration server by running the Integration Server command. IntegrationServer --work-dir <workDirLocation> --name <uniqueName>.  The name that you set for the integration server is used as the name of the runtime in webMethods Hybrid Integration. For more information, see IntegrationServer command in the App Connect Enterprise documentation. Set the unique name to “on-premise-ir”.
   IntegrationServer -w workdir --vault-key password --name on-premise-ir
9. Check the App Connect Enterprise console for messages that indicate that the integration server connected to the switch server in webMethods Hybrid Integration. BIP6450I: The connection agent for remote callable flows has established a connection to the Switch server with URL 'wss://default-switch-server-switch-....'.
   2025-06-19 14:42:26.374542: IBM App Connect Enterprise administration security is inactive.
2025-06-19 14:42:26.389164: The HTTP Listener has started listening on port '7600' for 'RestAdmin https' connections.
2025-06-19 14:42:26.726828: The connection agent for remote administration successfully registered using App Connect agent identifier 'b8c15821-64b5-4c02-84e5-475f52d16047'.
2025-06-19 14:42:26.727092: Integration server has finished initialization.

At this point you have a ACE runtime running on your local machine and it has registered with the webMethods Hybrid Integration switch server.

Now, from the header menu, navigate to the Integration runtime management capability.

You will also see some webMethods runtimes included if that capability is enabled.

To add the remote runtime click Register runtime, then App Connect runtimes. This will then prompt you to choose a deployment location. We are going to use the webMethods Hybrid Integration switch-deployment-location which the remote runtime is already registered with. You could also add any additional deployment locations which contain remote runtimes at this point.

After clicking next you will see the remote runtime available to add:

Click on the Add Runtime button and the remote runtime will become visible and manageable from the webMethods Hybrid Integration Integration runtime page:

You now have one remote and one IBM managed runtime setup to use. Both are enabled for callable flows. The final setup step is to deploy the Coffee_AI.bar file to the remote runtime. You can do this by opening the tile shown on the Runtime view and selecting the Deploy bar button. Do this and deploy the BAR file Coffee_AI.bar to the remote runtime.

You now have the two parts of your integration deployed; one to an IBM managed runtime and another to a remote “on-premise“ runtime you have set up. The next step will be to utilize these in a bigger integration flow to complete the full scenario.

Using Integration runtime management to view and administer attached runtimes.

Wherever you are in the webMethods Hybrid Integration product you can navigate to the Integration runtime management view by using the top header. Select the hamburger menu in the top header and select the Integration runtime management option:

From this single view you can drill into each Integration runtime to see what is in deployment and how it is configured. For example, you can open the remote runtime on-premise-runtime tile and then open on the application Coffee_Suggester_AI and within that, open up the deployed flow to see how it is constructed.

The exciting thing here is you are able to manage many runtimes distributed across many form factors all from one easy to use UI. Some basic administration actions are available, like deploying BAR files, or stopping and starting runtimes, but in the future, there will be more and more sophisticated administration actions added.

Depending on the type of form factor that ACE is running in will effect exactly what operations are available. For example, you cannot stop and start standalone ACE servers but you can do this for ones that are managed, or running on an integration node. In our case in this tutorial, customer-ir can be stopped and started but the remote standalone server on-premise-runtime cannot be.

You can try out the administration of customer-ir by selecting stop on the customer-ir tile:

It will then go into stopping state, and then finally into stop state:

Now we have the runtimes connected and administered, we can start using their capability both in other ACE flows and within webMethod Workflows.

Ensure you start customer-ir before continuing the tutorial otherwise the next sections will not work!

Using the webMethods Integration capability to construct the full integration logic.

We are now at the point where we have the key integration components for the scenario deployed but we want to pull these together to make one coherent integration that performs the full scenario. For this, we are going to use a webMethods Integration Workflow. This simple “no code” integration tool will be used to combine the already engineered ACE Toolkit integrations into the full solution.

The first step is to navigate to the webMethods Integration capability from the header menu:

At the top of the project view you will see the Callable flow tab. Select this and then click on Add flows. The system will then discover all the available callable flows in the system. In our case it should discover the two callable flows we have deployed. One in the IBM managed runtime, and another in the remote runtime. Select all of them and click Add.

By adding these to the project, they now will be available to use in a webMethods Integration Workflow. The person developing the Workflow does not need to have any knowledge about where they are running or how they are implemented. They will appear in the Workflow editor palette as a step they can use when authoring a Workflow.

webMethods is now fully configured with access to the App Connect flows, the next step is to write the Workflow. Navigate back to the Integration tab and select the big plus button. Select the Workflow tile when prompted for an integration type.

The Workflow editor will now appear. Rename the flow to “Recommendation”.

We are ready to start implementing the high level flow. There will be the following main parts to this:

1. Add a way for the flow to be triggered. 
2. A step to retrieve the customer details based on number plate.
3. A step to generate recommendations based on a customer’s details.
4. A step to send the information to the customer (or in our case, just to us).

This is a simplified version of what the full system would need to do but will demonstrate the key concepts.

The first step is to configure the trigger. Click on the first step in the flow which is pictured as a play step (blue triangle).

From the large number of triggers select the Webhook trigger. On the first screen add the following in the header section:  { "plate": "HF17QQQ"}.

Then click on Next and select to turn off authentication. Click on Next, followed by Done, to complete the Webhook setup.

Now to add in the number plate lookup. In the search box to the right of the screen type “Number”. This will be enough to find the number plate lookup step. Click on the step and drag it on to the workflow. It will automatically connect to the Webhook step.

As you can see, this step appears just as a built in step with no reference to callable flows, and can be used without any knowledge of where it is running or how it was implemented. To configure this step, double click on it to start the setup wizard. Click Next to get to the mapping screen. And now map the incoming Webhook plate field to the callable flow plate input field.

Click on Next and you will get to the test step. Click on Test to see if the callable flow can be called and return data.

You will get back a set of customer information which matches the number plate. When you selected Test, the webMethods Integration Workflow has seamlessly and securely called the App Connect Toolkit flow running in the managed instance. This step is now complete, so select Done.

The next step is to generate the customer suggestion. Type “suggest“ in the search box this time. You will then see the customer suggester. Click and drag this onto the Workflow and it will get attached to the previous number plate step.

Ok, double click on the new step and click Next to configure the mapping for the step. This time we will map customerNumber field from the number plate lookup to the call to find out the suggestion.

Click Next to take you to the test page. Click Test to execute the step. This time the workflow will call the flow running in the remote runtime.

Click Done to complete this setup step. 

For the final part of the flow we will add an email step so that we can send the result to our own email account - we would send this to our actual customer in reality.

In the search box type “email” and then select and drag it onto the workflow. It will connect itself to the suggestion step. To complete the wiring, connect it to the final Stop step as this will be the final part of the flow (step with the red square):

Double click on the email step to start the configuration. Select Next and then configure the email to take information from the previous steps to send to your own email address. For example:

Click Next to go to test view. Click Test and it should complete with an email sent to the email address you chose to use. Ensure that you click Save to fully save the new Workflow.

The Workflow is complete and can be fully executed by clicking on the play button in the top right hand header.

The logs in the bottom of the screen will show the steps as they execute and at the end you will receive the email with the food suggestion.

It is also possible to drive the flow properly using the webhook. To do this you need to open the webhook step and copy the provided webhook url. Then you can call the API externally using a tool like curl. For example:

curl https://envtest1.ibm.com/runtflow/run/sgsgsgs -H 'HF17QQQ'

Closing thoughts

From this simple scenario we have shown how webMethods Hybrid Integration can be used to write and manage integration logic across both IBM managed and self hosted runtimes from one central point.

This is only the start of what is possible within webMethods Hybrid Integration. Now that the runtime management is consolidated in the one place, the monitoring and administration across these distributed runtimes can easily be managed.

webMethods Hybrid Integration also has end-to-end logs which show how a single integration transaction flows across all the webMethods Hybrid Integration capabilities.

This extends beyond any single capability: API Connect, webMethods integration and App Connect can be included so that end-to-end logging between all three capabilities can be achieved per transaction. To start understanding all the amazing things webMethods Hybrid Integration can do, and to try this for yourself, take a look the webMethods Hybrid Integration product page.

If you have any more questions then please feel free to post a question here, or request a demo via the webMethods Hybrid Integration product page.