The APIs, by their very nature, are essentially the bridge between two or more interconnected systems. These systems facilitate their business processes, and they utilise the APIs to interconnect and exchange data for allowing an extended business process to be realised across multiple systems.
Any technology or solution, and in our case, the APIs, are susceptible to run time issues. When we run into runtime issues for APIs, it's generally a very cumbersome task to assess the root cause. The root cause could be related to any touch points within the entire data exchange lifecycle. The issue could be within the source system, related to the transmission of the data, or something at the receiving system. There could be security, authentication, network-related connectivity, and transmission issues.
There are other scenarios where a particular data exchange between two systems could fail. This could be related to the different level of validations APIs has to perform before the data can be committed to the underlying core objects.
Other areas of concern are the performance of the APIs. As API administrators and owners, we need to get a grip on the performance and be able to proactively check for bottlenecks.
While conducting root cause analysis, it is essential to be able to look under the hood. Generally, Administrators will look at multiple log files and sometimes have to invest multiple hours before a root cause for failure can be determined.
While looking for a solution to these issues, flexibility and quick turnaround for these assessments were on top of our minds.
Display Parameter (represented by "d"):
We created a "Display Parameter" option to allow users to control the overall governance of the API elements. The users can choose to include or exclude certain core elements of the API response.
The Display Parameter consists of the following Operators:
Data Operator - allows viewing the response element where the business data is included. The "data" element is displayed by default; however, it is not mandatory to retrieve the data element.
Stats Operator - allows viewing the performance statistics for the API. The "stats" operator exposes runtime performance timings in milliseconds.
Counts Operator - allows viewing only the counts of the records. The "counts" operator can be combined with another display operator to get the desired results. The count operator can be used independently if only the count is required sans any data.
Debug Operator - allows viewing the complete internal information on API processing. Users can only utilise the "debug" operator if they are part of the TRIRIGA "Admin" group. Furthermore, this operator is only to be used for temporary root cause analysis scenarios where there are any issues with the data exchange. The debug operator will document the processing steps in detail and identify any specific issues early in the troubleshooting phase.
The data and counts elements are displayed as a default; however, the behaviour can be adjusted based on the requirements using the display parameter.
Fig 1: Display Parameter
For further technical information, please click on the arrows below to expand the required list:
How do these operators work?
Data Operator:
Stats Operator:
Counts Operator:
Debug Operator:
This post is part of a series detailing the ExpressAPI Features and Capabilities.
If you need to discuss anything, don't hesitate to contact us through this link.
Please read our Privacy policy here.