Leverage Postman for Streamlined API Testing in Finance and Operations

Introduction

Postman is a tool for testing APIs.
It lets you send requests, automate tests, and share your work with your team. 

We're going to connect Postman to our Finance and Operations environment so we can test out standard or custom APIs.

I've already covered automating the testing in Postman in my blog here so once the connections are in place you'll be good to go!

Pre-requisites

1. Postman
2. Finance and Operations Environment

Configuration

We'll start with creating an App Registration in Azure Portal.

Go to the Azure Portal (of the same tenant of your FnO Environment).

Search for "App Registration" and click on "New Registration".

Add a name for your new app and click on "Register."

Once it is completed, you'll be taken to the Overview of the app.

Here, click on the "Add a certificate or secret" under the "Client Credentials."

Add an appropriate name and select the expiration date of the certificate as necessary.

Once you click on add you'll get the confirmation message that the client credential has been created and you'll be able to see the value of the secret.

** Be sure to copy this value and keep it securely as once we refresh from this page, this value will not be available.**

Now that everything is done on the Azure side, open your FnO environment and search for "Microsoft Entra Applications."

Click on "New."

Paste the "Application (Client) ID" into the "Client ID" field, then assign it a suitable name and a User ID. 

The permissions given to the User ID will determine the permissions for the App.

For now, I've assigned the "Admin" user.

That's all the configuration required at the FnO side.

Now, lets jump back into Postman.

Now, in Postman we'll start with a blank workspace and create a simple collection.

The first thing that I like to do is to create different environments.

As in FnO, we have a Production, a Sandbox and we can have multiple development environments so it may be possible that different environments are using different apps.

So to represent these environments, I like to create different environments in Postman as well.

This is done by going to the "Environments" then clicking on "+" to create a new environment and giving it the appropriate name.

Now, in this environment, I'll add my app details as environment variables.

The values for these can be found as follows - 

"grant_type" can be hard-coded to "client credentials" and we can leave "Curr_Token" as blank for now.

So, at the end we get -

We can also change the type to "Secret" so that no one else can see these values.

Now, the necessary credentials have been added to Postman.

Next, we'll set up our collection for generating the Auth Token.

For that, we'll copy the "OAuth 2.0 token endpoint (v2)" from the "Endpoints" in our Azure App Registration's Overview screen.

In Postman, click on your Collection then "Authorization" then select "OAuth 2.0"

I'll paste the URL we copied from the "OAuth 2.0 token endpoint (v2)" from the "Endpoints" in our Azure App Registration in the "Access Token URL" field and I'll add my variables as defined at the Environment variables.

If you get the error "Unresolved Variable" even after defining them, then it could mean that the Environment isn't set as the active.

So go back to the Environments list and mark it as active.

This way we can easily swap between Environments.

Once the environment is marked as Active, we can see that the variable is found correctly.

I'll also ensure that my Access Token URL refers to the tenant ID as per my variable by embedding my "tenant_id" variable in it.

Next, I'll click on "Get New Access Token."

If everything has gone well, you'll be able to generate the token successfully.

After that, you can give it a name and click on "Use Token" to use it.

I'll now create a simple API which we can use to test this token.

Right click on the "Collection" and click on "Add Request" give it an appropriate name.

The "{{base_url}}/data" returns a list of APIs available in the system.

I've set the Authentication to "Inherit Auth from parent" which means it relies on the Authentication set on the "Collection" for calling the request as is shown on the right side of the screen.

Here we see that the request was executed successfully.

If for some reason, you cannot use the standard Postman way of generating the Token, you can create a seperate API responsible for generating the Auth Token, store it as a variable and use it in your requests.

From here, you can use the generated "access_token" and pass it as a "Bearer Token" to your requests.

Or you can select the entire token and set it to your "Curr_Token" variable.

And then you can pass this variable to the requests like - 

From Postman, we can then share these collections (which contain API data) and environments (which contain credentials) seperately as needed.

All Data Entities follow the pattern - {{base_url}}/data/{{endpoint}}

All services follow the pattern - {{base_url}}/api/services/{{service_group_name}}/{{service_name}}/{{method_name}}

If I call a "Get" request on them, I get the details of the services for instance, here I'm getting the type of data I have to send in and the response I'll be getting back in the form of object names.

Moving back one step, I'm getting the names of the Operations (or methods) within this service object.

Moving back one step, I'm getting the services within this Service Group.

Moving back one step, I can see all the service groups available in the system.

To actually run the logic behind the services methods, I'll have to use a Post request.

Conclusion

Thus we saw how we can connect Postman to Finance and Operations environment and call APIs directly from Postman.