Creating an integration runtime

The BAR file for your exported flow contains all the resources that are needed to deploy an integration. To deploy this integration on the VPC hours plan, create an integration runtime to run the BAR file resources.

To deploy your integration, complete the following steps.

1. Open your App Connect Dashboard instance at the home page.
2. Click Deploy integrations.

   Alternatively, you can go to the dashboard tab of the Dashboard instance and click Deploy integrations.

3. On the Size tab, select the size of integration that is appropriate for the BAR file that you're deploying, then click Next.
   VPC, CPU, memory, and storage values are shown for each integration size. A virtual processor core (VPC) is a unit of measurement that is used to determine the licensing cost of IBM® products. The value is based on the number of virtual cores (vCPUs) that are available to the product. The CPU values on the tiles are measured in cores.
4. On the Integrations tab, upload a BAR file that you've created in the Toolkit or exported from Designer, or choose one that you've uploaded before, then click Next.

   You can drag a BAR file from your file system or click where indicated and select a BAR file from your file system. You can also specify one or more BAR files on the Properties tab. If you want to do that, leave the Integrations tab empty and click Next.

   If the selected BAR files don't match the size of integration that you selected on the Size tab, the VPC cost might be affected.

5. On the Configuration tab, select or create one or more configurations that you want to apply to the integration runtime.

   This step is optional, but you need to create configurations if you want to provide environment-specific information that your integrations need to work, like account credentials. To apply an existing configuration to your integration, select the checkbox of the configuration in the table. To create a configuration, click Create configuration, then select the appropriate configuration type. For more information, see Configuration types.

   If you're deploying a Designer flow that you exported as a BAR file, only the following configuration types are relevant.

   • Use an Accounts configuration to provide account credentials for your connectors. You can apply only one Accounts configuration to an integration runtime, but you can use it to provide credentials for multiple connectors.
   • Use an Agentx configuration if the deployed flow contains a Callable flow node that needs to use a switch server to connect to a callable flow in your network. You can apply only one Agentx configuration to an integration runtime.
   • Use a Private network agent configuration when the deployed integration needs to interact with an application in a private network. This configuration provides secure connectivity details to establish a connection. These details enable port forwarding from a local listening port that is opened for the deployed integration to the remote port and host of the application in the private network. You can apply only one Private network agent configuration to an integration runtime.

   If you're deploying a BAR file that you exported from IBM App Connect Enterprise Toolkit, you can select or create multiple valid configurations that apply to your BAR file.

   If you're deploying one or more BAR files that are stored in an external repository, use a BarAuth configuration to provide the credentials to connect to the repository.

6. After you select or create one or more configurations, click Next.
7. On the Properties tab, configure the integration runtime.
   You can either complete the form fields or provide the information in the YAML editor. You can also use the YAML editor to add properties that aren't shown in the Common settings view. To see more properties in the Common settings view, click Advanced settings.

   

   The following basic properties define the integration runtime.

   Name

   Enter a short name that uniquely identifies this integration runtime. You can use lowercase alphanumeric characters and hyphens (-) for the name, and it must start and end with a lowercase alphanumeric character.

   Channel or version

   Select the version for the integration runtime. You can select a specific fix pack version, such as 12.0.9, or a version stream, such as 12.0. The version stream resolves to the latest fix pack version when it becomes available.

   BAR URLs

   If you didn't provide a BAR file on the Integrations tab, you can add one or more BAR files by clicking Add + for the first file and Add another + for subsequent files. Specify the URL to each file with the file name, as shown in the following example.

   https://artifactory.com/myrepo/getHostnameAPI.bar,
   https://artifactory.com/myrepo/CustomerDatabaseV1.bar

   Tip:

   The BAR files that you specify must all be accessible by using the same authentication credentials; for example, basic authentication or no authentication. Define these credentials by creating a BarAuth configuration on the Configuration tab and make sure that the configuration object is selected. For more information, see BarAuth type.

   Replicas

   Specify the number of replicas to run for this deployment. You can define the number of replicas of an integration runtime to allow for high availability of the integration solutions. However, if you increase the number of replicas, you proportionally increase the resource requirements and the running cost. You can specify up to a maximum of 6 replicas.

   All replicas of an integration runtime share an HTTP hostname, and HTTP traffic is spread between the replicas. If one runtime replica fails or is restarted, the other replica runtimes continue to work. When App Connect Enterprise as a Service receives a system update, only one of the replicas is restarted at a time so that the other replicas can continue to handle requests.

   Tip: To later save the cost of running an integration runtime while you retain the definition, you can set the number of replicas to zero.

   Force flow basic auth

   Turn this property on to enable basic authentication on all HTTP input flows. Basic authentication provides secure access to HTTPInput and SOAPInput message flow nodes that are running in your deployed flows. If you enable basic authentication, HTTP requests to any HTTP or SOAP nodes on that integration runtime must specify the correct URL, a username, and a password. If you disable basic authentication, HTTP requests can access any of the HTTP or SOAP nodes on that integration runtime by using only the correct URL, and no username or password.

   To view the basic authentication credentials for the deployed runtime, go to the dashboard and open the tile for the runtime. You can find the basic authentication credentials on the Security tab. You can also regenerate the credentials for all integrations that are running in that runtime.

   To view the following advanced properties, click Advanced settings.

   Flow types

   When you deploy a BAR file, the types of flows that you're deploying are detected by inspecting the BAR file. Therefore, you don't need to specify the types of flow that you're deploying. However, if you're deploying multiple or large BAR files to an integration runtime, and the inspection is timing out, you can specify the types of flows that are contained.

   Make sure that you select the flow types for all types of flow in your BAR files. You can update the contents of a BAR file after it is deployed, but the initial flow types must remain the same.

   Containers

   When you deploy a BAR file, containers are created to provide runtime support for your flows. The type and number of containers that are created depend on the type of flow that you're deploying. The preconfigured integration runtime sizes on the Sizes tab are sufficient for most workloads. However, you can add and configure extra containers to customize the amount of resources that are assigned to your integration runtime to run your integrations. Values for the runtime container are shown by default, but you can add extra containers by clicking Add another +. For each container that you configure, set the Name field to the appropriate container. The name that you specify must be valid for the type of integration that you're deploying and can be one of the following containers.

   runtime

   The runtime container is deployed to provide runtime support for Toolkit integrations or Designer integrations.

   designerflows

   The designerflows container is deployed to support API flows in Designer integrations. This container also hosts action connectors for event-driven and API flows.

   designereventflows

   The designereventflows container is deployed to support event-driven flows in Designer integrations.

   For each container, set appropriate values for the CPU limit and Memory limit.

   CPU limit

   The CPU limit is the maximum amount of CPU time that is available to the container in cores. You can define the limit as an integer or fraction (for example, 1 or 0.5). Alternatively, you can define the limit in millicores (for example, 100m is one hundred millicores, which is equivalent to 0.1 cores). A single container can contain a maximum of 4 cores of CPU. An integration runtime can contain a total maximum of 8 cores across all containers, including the default containers that are created with the integration runtime. For more information, see CPU resource units in the Kubernetes documentation.

   Memory limit

   The memory limit is the maximum amount of memory (in bytes) that is available to the container. You can define the limit as an integer that represents the number of bytes, or you can add a suffix that specifies the quantity (for example, 1024M is equivalent to 1024 MB, and 1G is equivalent to 1 GB). For more information, see Memory resource units in the Kubernetes documentation.

   The ratio of CPU to memory is limited to 1:2. For example, if you assign 0.5 CPU cores to your runtime, the maximum amount of memory that you can assign is 1 GB. Similarly, if you assign one CPU core, the memory limit is 2 GB. If the deployed BAR files don't match the size of the integration runtime, the VPC cost might be affected. You can monitor CPU and memory usage for your integration runtimes after deployment. For more information, see Monitoring resources.

   Note: The following properties aren't currently supported in App Connect Enterprise as a Service because the IBM product team controls them.

   • Image path & tag
   • CPU request
   • Memory request

   Default app name

   Specify a name for the default application for the deployment of independent resources.

   If your integration contains independent resources that aren't in an application, they're added to the integration runtime default application when the integration is deployed. If you enter a name in this field, a default application is created with this name. If you don't enter a name, the default application is called DefaultApplication.

8. After you configure the integration runtime, click Create.

Results

The integration runtime is displayed as a tile on the dashboard tab of the Dashboard, with an initial status of Pending, which changes to Ready when the deployment completes. (Refresh the page to see the change in status.) Your deployed integrations are now waiting to be triggered or called.

When the runtime is ready, use the menu on the tile to open, edit, or delete it. You can also change the version (see Updating the version of your integration runtime) and manage user and service trace (see Collecting trace for deployed flows).

When you open the runtime, use the tabs to see things like the integrations in your runtime, or the runtime's properties, or the basic authentication credentials.