7. Locate the Policy menu item on the left. Notice how the page just shows the invoke policy. When we start applying logic to the API, this screen will be updated to show visually how the flow will be executed:

Figure 6.15 – Default policies for FHIR API

Now that you have familiarized yourself with the default implementation, it’s time to make some updates so we can test our API. The changes you will make will be adjusting the target URL and the basepath, so it adheres to the endpoint: http://hapi.fhir.org/baseR4/Patient?_pretty=true:

1. Navigate to the Design tab and select Base Path. Change /fhir-server/api/v4 to /baseR4 and click on Save:

Figure 6.16 – Updating the base path

Figure 6.16 shows the results of your change. What you just did was adjust the base path to match the target endpoint URI to specify /baseR4 versus the default that was provided in the download. When the API executes, API Connect will then append the new base path to the host endpoint. Next, you’ll update the target host within the targetURL property.

2. Navigate to the Gateway tab and select Properties. You will notice targetURL. Click on the link to allow for changes.

Notice that the default value is https://localhost/fhir-server/api/v4/. You will be changing this to http://hapi.fhir.org. Make that change and click Update, and then click Save once again.

3. While still on the Gateway tab, you need to adjust the invoke policy that you saw in the Policies section.

You should see the single invoke policy. Click on the policy itself to open the property editor:

Figure 6.17 – Invoke property editor

As you can see in Figure 6.17, the URL property has the following replacement properties:

 $(targeturl)$(api.operation.path)$(request.search)

You are already familiar with target-url. The other two are context variables. You were introduced to context variables in Chapter 4, API Creation. When you want to utilize the submitted path to an operation, you reference the api.operation.path context variable. If you reference request.search, you are essentially taking the request details after the question mark. An example would be http://hapi.fhir.org/baseR4/Patient?_pretty=true.

You will adjust these to reflect the changes you want to make. In the URL property, change the value of $(targeturl)$(api.operation.path)$(request.search) to $(targeturl)$(api.root)$(api.operation.path).

This will now call the backend API using the values you changed. You should test it to verify it is working. Ensure your API is online. If it shows offline, slide the button to online.

Once your API is online, click on the Test tab and perform the following steps:

1. On the Test panel, use the Request dropdown to see GET https://localhost:9444/localtest/sandbox/baseR4/Patient. This is shown in Figure 6.18.

You may have noticed that API Connect had all of the HTTP methods support – a real timesaver. Click Send to invoke the API.

2. If all goes well, you will be returned the JSON payload from the FHIR server (shown in Figure 6.18). If any errors occur, you will need to research the errors. If you make corrections to the API, ensure you save it, and then execute these steps again:

Figure 6.18 – Successful patient results from the test

You have successfully created and tested an FHIR GET request and have seen data returned. You did that with very minimal steps.

Before you learn about adding logic policies, let’s first move your API up to the API Manager so you can experience development and testing on that platform.

Important Note

It is an assumption that you have access to the API Manager and belong to a provider organization. If you have yet to get access to the API Manager, please request access from the provider organization owner. To get to the API Manager user interface, use this URL: https://[api-manager-server-ui]/auth/manager/sign-in/.

3. Next, log in to the API Manager and select Develop APIs and products:

Figure 6.19 – Using the API Manager for development

You will be presented with a list of existing APIs. This is a list of all the APIs within the provider organization.

4. Click on the Add button and choose API (from REST, GraphQL, or SOAP) so you can import the Patient API file you created with the LTE. Drag and drop your API or click to upload the file using a file browser that pops up to select the API.

5. Choose Existing OpenAPI and select your Patient API file:

Figure 6.20 – Importing the Patient API file to the API Manager

Your API is now available for additional development in the API Manager. You might notice that the page display is very similar to the LTE environment:

Figure 6.21 – Patient API viewed on the API Manager

Now, it’s time to add some logic constructs to your API to allow greater flexibility.