The buzz surrounding API’s seems to suggest that merely creating an API already makes it valuable. Even though the advantages of API’s are easily recognized by IT teams, convincing the rest of the functional units in your business can be daunting. Especially, if the argument cannot be related to the bottom-line. The best way for an IT-organization to present its case is to demonstrate how API usage can become part of the revenue stream.
Introduction
Having gone through our (ESB) considerations of choosing an integration platform, and being assured that there are no hidden cost or vendor lock-ins with the WSO2 platform. You have integrated some disparate systems in your IT environment by creating proxies and/or APIs in your ESB. These API’s are managed by WSO2 API Manager and yet these efforts are not traceable on the income statement.
Indeed, an adept IT-organization would attach its projects to particular business objectives and derive success from the accomplishment of those aims. However, this is still a derivation and not directly traceable to money saved or gained from exposing those API’s. With paid access to your content through WSO API Manager, your efforts have the intended impact on the financial reports. This assertion holds, even if all subscribers of your API are internal to your organization.
How do you monetize your WSO2 API Setup?
WSO2 API Manager ships with a configurable payment scheme to monetize API usage. It is based on a direct-access model and when enabled in WSO2 APIM Publisher (registry location /_system/config/apimgt/applicationdata/tenant-conf.json) allows the throttling tiers to act as billing plans for a subscription.
Retrieving the actual usage data requires WSO2 Analytics Server (WSO2 DAS) though. Since the data generated by the API gateway component is sent to WSO2 DAS for analysis. This processing allows WSO2 DAS to gather information relating to request, response, fault, throttle, destination and workflow from the gateway component. The aggregated information in WSO2 DAS for each subscribed application to an API, can then be retrieved by an invoicing/accounting software.
This approach is demonstrated in three (3) steps using the following products:
| WSO2 API Manager | Version 2.0.0 |
| WSO2 Analytics Server (WSO2 DAS) | Version 2.0.0 |
Step 1: Configure WSO2 API Manager Components
API Manager 2.0.0 is slightly different from its predecessor due to the separation of throttle management from the gateway component. So in a distributed setup like in the image below, care should be taken to set the right configurations in the appropriate files. Also, note that a proper CN certificate should be used for the communication between the components.
API Key Manager
The Key Manager makes use of the USER DB and APIM DB, and these data source configurations must be present in the master-datasources.xml file. In editing the api-manager.xml file, remember to set the api-gateway URL, disable analytics and throttling for this component. When using thrift client for key-management-related communications between the Key Manager and the Gateway, note that the Key Manager is always the thrift-server. Start the instance with the argument -Dprofile= api-key-manager.
API Traffic Manager
The Traffic Manager executes throttle policies against requests that come to the gateway and sends the decision to a JMS topic subscribed to by the Gateway. It is the only component in this setup with a message-broker store in the database. The Traffic Manager component requires the regular registry.xml file to be replaced by the registry_TM.xml file and axis2.xml file should be replaced by the axis2_TM.xml file.
Also, existing web – and jaggery apps in the <Trafficmanager>/repository/deployment/server directory should be deleted and the product instance started with the argument -Dprofile=traffic-manager.
API Gateway
The API Gateway only deals with serving requests that come to it by applying policies (security, throttling, etc.) and publishes usage statistics to the analytics server. In this setup, the API Gateway does not share any database instances with the other components. The api-manager.xml file is the primary focused for configuration.
Apart from the usual configuration of the APIKeyValidator and AuthManager elements, analytics and throttling should be enabled as well. Analytics settings should point to WSO2 DAS endpoints and throttling configurations should look to the Traffic Manager. As this is a single instance of the Gateway, the server should be started with the argument -Dprofile=gateway-manager.
API Store
In addition to the USER DB, APIM DB and REG DB settings in the master-datasources.xml file and their related settings in the user-mgt.xml, registry.xml, and api-manager.xml files. Clustering needs to be enabled in the axis2.xml file.
Since the throttling tiers act as the billing plan, the usual subscription creation process in the API store will have to be extended. This extension enables a redirection to the Invoicing/Accounting software to decide on the merits of subscriptions. As shown here, a jar file is created and the new subscription workflow enabled in /_system/governance/apimgt/applicationdata/workflow-extensions.xml. As with the other components, the server is started with the profile argument -Dprofile=api-store.
API Publisher
The settings in the API Publisher are comparable with that of the API Store. The difference is making sure the clustering member is the API Store and starting the server with the argument -Dprofile=api-publisher.
Step 2: Configure WSO2 AM Analytics (WSO2 DAS)
In this demonstration, a standalone instance of WSO2 DAS can be started without any arguments. It makes the setup very simple. WSO2 DAS is required to push statistics data into the WSO2AM_STATS_DB data source and therefore the stats-datasources.xml file should be configured as explained here and here.
Step 3: Connect Invoicing/Accounting software
The Invoicing software needs to be able to make RESTful calls to authenticate itself and query WSO2 DAS. The querying of WSO2 DAS in this instance would have to retrieve information regarding successful requests that met quota, as well as throttled-out requests that were successful for a subscriber. This information will be an aggregated interpretation created by a Spark SQL script involving the summarized tables API_REQUEST_SUMMARY and API_THROTTLED_OUT_SUMMARY as explained here.
Conclusion
In three steps, of a distributed setup of WSO2 API manager, analyzing the generated data from the gateway component with Analytics server, and requesting that analyzed data into an invoicing/accounting software, the ability to monetized the efforts of an IT organization (with regards to implementing an API) is realized. Therefore, whenever financial reports are generated, the hard work of the IT organization is represented with actual figures.
