Logging in to API Manager – Digital Transformation with IBM API Connect

0 Comments

The first thing you must do to interact with API Connect is to log in. You will be logging in as a Provider. The last command you ran provided you with the user registry to use (that is, default-idp-2). You will use that registry in the login command. You can run the apic login command by passing in all of the arguments or by issuing it interactively:

apic login –username <isoadeveloper> –password <password> –server < api-manager-ui.apicisoa.com > –realm provider/default-idp-2

You can choose either. Doing it interactively is shown here:

apic login

Enter your API Connect credentials

Server? <api-manager-ui.apicisoa.com>

Realm? provider/default-idp-2

Username? <isoadeveloper>

Password?

Warning: Using default toolkit credentials.

Logged into api-manager-ui.apicisoa.com successfully

All of the arguments are pretty straightforward. Only with realms can you specify it a little differently. Here, you provide the realm with the scope value and registry demarcated with a slash: provider/default-idp-2.

If done properly, you will get a successful message. If you are planning on working within a particular Catalog for multiple commands, it’s useful to set your configuration to point to a Catalog as the default.

Setting the target Catalog and Provider organization for deployments

Often, you might be deploying several products to the same Catalog. By setting a configuration setting for Catalogs, you can omit the need to specify a Catalog when deploying. You can also do the same for Provider organizations:

  1. To set configurations, you can use the apic config:set command. To set a Catalog, you specify a URL. This restful format is useful to remember for the future. The format is as follows:

[Hostname of the API Manager]/api/catalogs/[name of organization]/[catalog name]

You must know the Provider organization and Catalog name ahead of time. Executing the command will set the Catalog in the configuration:

apic config:set catalog=<https://api-manager-ui.apicisoa.com>/api/catalogs/<middleware>/<sandbox>

catalog: https://api-manager-ui.apicisoa.com/api/catalogs/middleware/sandbox

2. Setting the Provider organization follows the same format, but the first argument changes from a Catalog to an organization. Now you can set the middleware organization as the default in the configuration:

apic config:set org=<https://api-manager-ui.apicisoa.com>/api/orgs/<middleware>

org: https://api-manager-ui.apicisoa.com/api/orgs/middleware

Since both of the commands returned successfully, everything is fine. However, you can validate that they are set if you wish to.

3. Check the configuration settings that you applied. To do so, you simply issue the apic config:list command:

apic config:list

catalog: https://api-manager-ui.apicisoa.com/api/catalogs/middleware/sandbox

org: https://api-manager-ui.apicisoa.com/api/orgs/middleware

So far, you have learned some general commands that are useful to you, the developer, and other roles, such as the DevOps engineer. They will be using the same commands to orchestrate the DevOps pipeline in the future.

With the basics out of the way, it’s time to draft some FHIR APIs and Products. You will do this with the draft CLI commands. Those commands take the form of apic draft-products:create and draft-apis:create.

You can use the apic draft-products:publish command to publish a product that’s already present in the drafts. First, create and upload a draft API.

Creating and uploading a draft FHIR API

You can view API drafts in API Connect when you are undergoing development. A draft is an API that is currently being worked on. You can find draft APIs on API Manager under Develop API and products. This is where you perform the development of API definitions and other functions such as deploying products, changing life cycles, and applying security to your APIs:

Figure 2.21 – Developing APIs and products

You can log in to API Manager to investigate how APIs are shown under Develop APIs and products. However, for now, we will continue with using commands to drive the flow:

  1. On the GitHub site, as noted in the Technical requirements section, you will find two FHIR swagger files that you can play with. They fully support version 4.0.1 of the FHIR specification. Copy those files to your workstation so that you can try out the commands using these files.
  2. Bring up Command Prompt and navigate to the folder where you copied the FHIR swagger files. You can view the files if you want to see more of what is contained, but for now, assume the files are fine. Let’s convert one of the swagger files into an API Connect draft.
  3. Creating a draft of an existing file is very easy. You will use the apic draft-apis:create command and pass in the appropriate arguments. There are only three required arguments:
    • The filename
    • The organization where the draft will reside
    • The server
  4. Since we have already set the configuration for the organization, you only need to pass the filename and server. Run the following command:
    apic draft-apis:create -s
    condition-api:4.0.1 https://api-manager-ui.apicisoa.com/api/orgs/7c642f84-5028-43a7-89df-6cf2a5b7adc8/drafts/draft-apis/17c10964-35a2-4010-ac73-fe92d312d8b4
    The results are displayed along with a unique identifier. This identifier can be used to reference this API if we need to automate some behavior that can access this file in the future.
  5. You can now log in to API Manager and review what just occurred:

Figure 2.22 – The draft created by the CLI

When you navigate to API Manager and select Develop APIs and products, you will find the newly created condition API, which is ready for customization. Next, you need to create a product so that you can publish it to a Catalog. You can certainly use the apic draft-products:create command to create a product and place it in the Develop APIs and products section within API Manager, but that will rely on a user working with the user interface, adding the APIs, and promoting them manually. That is one way many people do it, but you should be able to take APIs and products and deploy them directly from your build server. This is what you will learn how to do next.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts