Recently a customer reached out to me to ask how they would go about building a dashboard for monitoring the consumption of their credits. Whilst my recommendation would always be to use the Excel Export under the Usage Analytics tab since this data is in an easily consumable format for easy manipulation into pivot tables for example. In this case however there were additional requirements I won’t go into that practically speaking a dashboard consuming the API’s was the only way forward.

BTP has two types of contracts, the first one is the one all SAP Users are familiar with, which is the Subscription model. In this case you purchase a named set of services for a specific duration and then you extend the order if you require more services. The second contract type is the Cloud Platform Enterprise Agreement or CPEA. In this model you pre-purchase a number of credits and then draw down on these credits as you consume them.

With the release of feature set B, there were a whole slew of new API’s and CLI’s introduced. Sadly these API’s only apply to Global Accounts that have a Consumption Model contract though this does make sense as subscriptions are not consuming credits since they have been paid for upfront as a fixed cost.

How do we programatically access these API’s to consume the billing data. Well we will show how in the rest of this blog post.

Setting up the environment

To start off with, according to the documentation you need to be a Global Account Administrator, though I think is it sufficient just to be a Global Account Viewer as this should have the requisite roles. If anyone knows different please let me know as I was unable to check with just a Global Account Viewer role collection. What this means is that the API should be put into some middleware where the access to the backend and service instance is not exposed to the consumers directly.

In order to consume the billing API’s we will need to use the SAP Usage Data Management Service for SAP BTP service in the BTP portfolio. This service is used to expose the API data but luckily it is a free service so there is no charge.

To consume this, first a subaccount is needed in Cloud Foundry, so go ahead and create a subaccount.

Next, in the Global Account cockpit assign the  entitlement to the newly created subaccount.

Please note that your available plans should not be greyed out. In this screen shot they are greyed out as I have already assigned the entitlement to the subaccount. Save the  changes to the entitlements to the subaccount.

Now go to the subaccount and create an instance of the Usage Data Management service from the Service Marketplace

Click the create button to create the new instance. Once the instance is created go to the Instances and Subscriptions panel and under instances verify the new Usage Data Management instance is created. Click on the instance to open it up and then in the Service Keys panel, create a new service key

This will now activate the “View Credentials” button on the top right which is where we want go to get the necessary details to connect to the service instance.

Make a note of the most important properties now. These are the clientid, the clientsecret, the url and target_url. These are the key pieces of information we need to create an oAuth token.

For the next stage we need to use postman to create the oAuth2 token and then access the data.

Configuring Access

The API’s for the billing can be accessed from the target_url with api as the path. This will like https://uas-reporting.cfapps.eu10.hana.ondemand.com/api in the case of the service being created in the eu10 landscape.

For this exercise we will use the subaccountUsage API to get the usage. Open up the PostMan app as we will use this to get the data which is a good way of understanding how it works under the hood and then can easily be applied to actual coding.

Some important things to note in the above image. We are on the Authorization tab and the oAuth 2.0 type is chosen for authorization. We are also adding the authorization data to the request headers and not the url.

The grant type should be “Client Credentials”. The clientid and clientsecret are obtained from the service instance. The Access Token Url is obtained from the url property in the service instance with a path of “/oauth/token” added.

Click on “Get New Access Token” at the bottom will request a new oAuth token to use.

Click the “Use Token” button to save this token and make it the default for the API call.

Finally we have the token so the last stage can be run to get the data.

Getting the data

The last thing we need to do is use the “target_url” in the service credentials as the base to get the data from the data from the data management service instance.

For the path we will use /reports/v1/subaccountUsage which will return the usage in the subaccount.

Using the API documentation in the {target_url}/api as documented above we see that this API requires a number of parameters.

To find the subaccount id we can find this on the Overview panel of the main subaccount screen.

Click the “Send” button to load the data

And there you have it, the billing data for the global account.

Hope this proves to be useful as a means to get the data for your own tooling and processes.