Sample scenario for invoking the API for IBM App Connect in containers (Red Hat OpenShift)

Step 1. Create an App Connect Dashboard instance

To begin, let's create an App Connect Dashboard instance by using the Red Hat OpenShift web console.

The following example shows the custom resource (CR) settings for the Dashboard instance. An AppConnectEnterprise* style license is specified, and Keycloak and the API are both enabled by setting spec.authentication.integrationKeycloak.enabled, spec.authorization.integrationKeycloak.enabled, and spec.api.enabled to true. For more information, see App Connect Dashboard reference: Creating an instance from the Red Hat OpenShift web console.

apiVersion: appconnect.ibm.com/v1beta1
kind: Dashboard
metadata:
  name: db-fd-acecckcloak-rc1
  labels:
    backup.appconnect.ibm.com/component: dashboard
  namespace: ace-fiona
spec:
  license:
    accept: true
    license: L-QECF-MBXVLU
    use: AppConnectEnterpriseProduction
  pod:
    containers:
      content-server:
        resources:
          limits:
            memory: 512Mi
          requests:
            cpu: 50m
            memory: 50Mi
      control-ui:
        resources:
          limits:
            memory: 512Mi
          requests:
            cpu: 50m
            memory: 125Mi
  switchServer:
    name: default
  authentication:
    integrationKeycloak:
      enabled: true
  authorization:
    integrationKeycloak:
      enabled: true
  api:
    enabled: true
  storage:
    size: 5Gi
    type: persistent-claim
    class: ocs-storagecluster-cephfs
  replicas: 1
  displayMode: IntegrationRuntimes
  version: '12.0'

Step 2. Create a Keycloak user for the App Connect Dashboard instance

After the Dashboard is deployed, we need to log in to the Keycloak Admin Console to create a user who is permitted to access the API and administer resources in the Dashboard. From the Red Hat OpenShift web console, we can access the Details tab for the Dashboard, and then use the Keycloak UI link to access the Keycloak Admin Console.

In the Keycloak Admin Console, we need to first switch to the cloudpak realm. Then, we'll create a user (fd-apiuser) and set a password for this user.

To ensure that the new user is authorized to interact with the API, we need to assign the dashboard-admin role (and optionally dashboard-viewer) to user fd-apiuser.

We can now return to the Red Hat OpenShift web console to view the Dashboard instance details, and then use the Dashboard UI link to log in to the instance as user fd-apiuser.

Step 3. Generate an access token for authenticating to the API

To use the API to administer resources in the Dashboard instance, user fd-apiuser first needs to generate an access token for authenticating to the API. We can use a UI-based tool to make a POST request for this token by specifying the following input:

• An endpoint URL for the token object, which is constructed by appending the /api/v1/tokens operation path for the POST method to the base URL of the API; for example:

  https://db-fd-acecckcloak-rc1-api-ace-fiona.apps.acecc-cd-414-amd64.abc.com/api/v1/tokens

  From the Red Hat OpenShift web console, we can obtain the base URL of the API from the API link in the Dashboard's details.

  
• The Keycloak username and password for logging in to the Dashboard.

{
    "accessToken": "tokenValue"
}

The following example shows the request and response in the UI-based tool.

User fd-apiuser is now authorized to use the supported HTTP methods to make API calls to create, read, update, or delete BAR files, configuration objects, integration servers, and trace objects in the Dashboard.

Step 4. Make an API call to upload and store a BAR file to the content server in the App Connect Dashboard instance

As a final step, we'll make an API call to upload a BAR file to the content server in the Dashboard. At this stage, the Dashboard contains no BAR files.

To begin, let's check the Bar file section in the IBM App Connect API documentation to see which method and operation path are suitable for uploading BAR files. A PUT method is defined with a /api/v1/bar-files/{bar-file} path, which we can copy by using the Copy to clipboard icon .

We can now construct the endpoint URL for the request by appending /api/v1/bar-files/{bar-file} to the base URL of the API. We also need to replace {bar-file} with the name of the BAR file to be uploaded; for example:

https://db-fd-acecckcloak-rc1-api-ace-fiona.apps.acecc-cd-414-amd64.abc.com/api/v1/bar-files/Customer_API.bar

To call the API, we can use our UI-based tool to specify a PUT method and the endpoint URL. We also need to select a locally stored BAR file (Customer_API.bar) that we want to upload to the content server in the Dashboard.

To authenticate to the API, we can specify our access token (from a previous step) by using an auth type of Bearer Token.

When we send the request, a 201 Created status is returned with a response body that provides the BAR file name and the location where the file is stored in the content server.

{
    "name": "Customer_API.bar.bar",
    "url": "https://db-fd-acecckcloak-rc1-dash.ace-fiona:3443/v1/directories/Customer_API.bar?87272da4-404d-48a0-991d-abe6fb91d409"
}

The following example shows the response status code and response body in the UI-based tool.

If we return to the Dashboard instance and go to the BAR files page, we can now see the BAR file that was uploaded by our PUT request.