Archive for category: IRT

For a customer project, we have been using SAP API management to secure our API’s. It is a good way to expose Odata from a SAP Gateway in a way that cloud applications can communicate with. It is fairly simple to setup Oauth to allow users to have valid authentication.

We did run in a problem about how to monitor the application. What happens if an unauthorized requires is found, a spike arrest or other requests that fail. In the logging, you will be able to see that there is an error but you will not be able to pinpoint the data anything but a few error codes. We have added an option to log some users on the Backend but we also want to be notified if something unexpected happens and be able to drill in to the data.

Check how easy it is to find errors with the solution

How to log errors in API Management

The standard approach is to add logging to Loggly or other services where you have a syslog listner. You will then put the logging in a place where it makes sense. If you forinstanace have some spikearrest problem that somebody is trying to take down your service, then you don’t want to log all the events to your logging service.

The ideal place to set the logging cloud either be on the post flow after the request have been delivered to the client. This is okay as long as there are no errors occurring. If there are errors and you want some special logging for the errors there are the default error flow or standard error flows. This setting is described in the blog, here it states that you will need to edit the policy files manually, because the UI is not up to date yet.

I have opted to use the KeyValueMap(kvm) policy to store alerts in. It is the only local storage that exists on the API server that you can access, it is clustered and high performance. Also you have the option to save errors only once so that mean if you have an error like Spikearrest then you really don’t want to know if it have occured at some point in time. So we can duplicate entries and then read them later. It is not the best solution for it but it is pretty simple to implement and you will be able to use it fast to get started. You may consider other solution later for reporting if you want to be able to drille deeper into the problem.

We have added the following script to create a JSON payload message that can be parsed with the information.

var apiProxyFigafPoliciesVersion = '1'

var logdata = {
    messageId: context.getVariable("messageid"),
    currentSystemTime: context.getVariable("system.time"),
    clientReceivedStartTime: context.getVariable("client.received.start.time"),
    timePassedAfterClientReceivedStartTime: context.getVariable("system.timestamp") - context.getVariable("client.received.start.timestamp"),
    messageQueryString: context.getVariable("message.querystring"),
    requestUri: context.getVariable("request.uri"),

    apiProxyName: context.getVariable("apiproxy.name"),
    apiProxyRevision: context.getVariable("apiproxy.revision"),

    faultName: context.getVariable("fault.name"),
    errorContent: context.getVariable("error.content"),
    errorMessage: context.getVariable("error.message"),
    errorStatusCode: context.getVariable("error.status.code")
}
context.setVariable("figaf.irt.apim.proxyerrorkey", logdata.faultName + "-" + logdata.apiProxyName)
context.setVariable("figaf.irt.apim.logmsg",JSON.stringify(logdata));

Then we can log the value with the code to our KVM figafIrtErrorKVM

<!-- apiProxyFigafPoliciesVersion="1" -->
<KeyValueMapOperations mapIdentifier="figafIrtErrorKVM" async="true" continueOnError="true" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <!-- PUT stores the key value pair mentioned inside the element -->
    <Put override="true">
        <Key ><Parameter  ref="messageid"/></Key>
        <Value ref="figaf.irt.apim.logmsg"></Value>
    </Put>
    <!-- the scope of the key value map. Valid values are environment, organization, apiproxy and policy -->
    <Scope>environment</Scope>
</KeyValueMapOperations>

We then add the two javascript policy and the KVM policy to the default flow for the process.

You will need to read the entries in the KVM to see the errors that have occured. There is an API that you can call that will give you that information. We did find that since this was clustered in some way you needed to force it to update

/apiportal/api/1.0/Management.svc/KeyMapEntries('errorKVM')/keyMapEntryValues?forceUpdateFromRT=true&$format=json

Once we have read the file we can delete each entry.

After getting some errors we get a KVM that looks like the following. There are individual messages with errors and also some global errors like spikearrest for one API.

Rule processing

Once you are downloading the messages you want an easy way to send a notification when something like the errors occurs. We have rewritten our rule processing to allow us to handle more complex rules and process them more effecintly. This mean that you will be able to send email notifications, or send webhooks that will sent the notification to Slack, Jira or where you have your support team listening.

I do have some ideas on how we can make a regresion testing possible. When more customers are adopting using the API Management process from Figaf then it could be possible to add it to support customers.

Want to try it out on your own system then try to see below.

Figaf also support the use of change tracking and transport of SAP API management.