As you can see, operation-switch shows readable cases so that you can understand what they will be doing. We can make it more readable by changing the invoke policy to a more descriptive name. To do so, perform the following steps:

1. Click on invoke to bring up its property pane. Change Title from invoke to get Evidence by id:

Figure 6.58 – Updating the title from invoke to get Evidence by id

After you make that change, operation-switch will be updated:

Figure 6.59 – Updating the title for the invoke policy

It is definitely more readable. Now, you will need to place the get Evidence by id invocation under the readEvidence case. Drag and drop the get Evidence by id invoke policy on the line under readEvidence:

Figure 6.60 – Drag Evidence by id to readEvidence

Now, whenever a readEvidence operation (GET) is called, get Evidence by Id will be invoked.

You will now need to test the conditional switch, but first, you need to update the base path and invoke URL. Since you are still on the Invoke pane, you should update the invoke properties now.

2. On the invoke pane (now called get Evidence by id), find the URL field and change the current value from $(target-url)$(api.operation.path)$(request.search) to $(target-url)$(request.path).

3. Click Save to save your assembly work. You’ll update the target-url property base path next. Click on the Design tab.

4. Scroll down and select General | Base Path. Change the base path from /fhir-server/api/v4 to /baseR4:

Figure 6.61 – Update base path to FHIR path

5. With the base path updated, you next need to update the target-url endpoint. Make sure to save the API by pressing the Save button.

6. Click on the Gateway tab and locate the Properties menu item. Click on Properties and select the target-url link. Change the property value from https://localhost/fhir-server/api/v4/ to http://hapi.fhir.org/.

7. Save your changes and then click on the Test tab. If the Test tab is disabled, change the slider from Offline to Online.

You’ll be presented with a page that will allow testing. One of the benefits of using the Test facility is it already has all of your operations available for execution – a real timesaver. It also knows the parameters that are required and displays them:

Figure 6.62 – The test tab is used to test the API

8. On the Test page, use the dropdown to select the GET request that is calling https://<host>/sandbox/baseR4/Evidence/{id}.

9. In the Parameters section, update the required id field and enter 1610421 as the value.

10. Click Send to initiate the request to the FHIR server. The response will return the Evidence FHIR resource with the ID of 1610421, as shown here:

Figure 6.63 – A successful test

You have successfully executed one of the operation-switch cases. But what about the other two that you set up? If you test them, nothing happens. It’s because we need to add invoke policies to the other two. You’ll do that next:

1. Return to the Gateway tab and drag and drop an invoke policy on the updateEvidence case. The properties will display invoke, and you should update the title and URL. Change the invoke title from invoke to put Evidence by id.
2. Replace the URL with $(targeturl)$(request.path). Your screen should look like Figure 6.64:

Figure 6.64 – Adding a new invoke policy for updateEvidence

3. Now, perform the same steps you just did but instead drop the invoke policy on the deleteEvidence case and change the title of the invoke policy to delete Evidence by id. Finally, you will also update the URL with $(target-url)$(request.path).

After saving your changes, your final operation-switch should look like Figure 6.65:

Figure 6.65 – Completed operation-switch with three operations

You have now successfully implemented an operation-switch. With this pattern of developing with the operation-switch, you can now add additional policies before and after your new invokes (get Evidence by id, put Evidence by id, and delete Evidence by id).

Information

The HAPI FHIR server is available for testing online. If you will be testing using operations that update and delete resources, it is suggested that you create a new resource first, save the return identifier, and use that identifier in future operations.

This concludes the steps to creating RESTful services using API Connect. You’ve learned a lot, so let’s review the key skills learned.

Summary

While this chapter was rather lengthy, it was packed with good information. You were introduced to FHIR and how that digital framework is helping healthcare companies successfully exchange information securely. You even learned with actual FHIR resources defined with data definitions.

You learned more about how RESTful services are created in API Connect and utilized the API Manager drafts to perform the visual development. Within the Develop APIs and products tile, you learned how to add existing APIs, modify those APIs with the designer, and add logic to flows such as operation-switch. The skills you learned in this chapter will make you very comfortable adding new or existing APIs, and then enhancing the flow of the API using logic constructs.

Finally, you were introduced to the Test facility where you can run a test directly from API Connect and how that facility improved your agility by generating your operation calls.

Your knowledge is building rapidly. The next chapter will build on this one by adding security to your APIs.