IBM Support

Repeating error messages logged by ApiHelper class

Troubleshooting


Problem

In Sterling Order Management, once APIs and services are invoked through custom code, if an error is encountered, the ApiHelper class repeatingly logs the same error message and stack again and again.

Cause

Normally, APIs and services are invoked through a wrapper class like InteropHttpServlet or IntegrationAdapter. If they are invoked through custom code using YIFApi, the ApiHelper class will be an additional wrapper. As such, once an error occurs, the OOTB wrapper (e.g. InteropHttpServlet) will log the error message and stack, and so does the ApiHelper class. The error message will be logged for each invocation.

Diagnosing The Problem

The repeating error messages can be seen in the sci.log file. For example:


2014-02-25 18:03:40,418:ERROR :WebContainer : 5: Caught wrapped exception invoking API [system]: ApiHelper
2014-02-25 18:03:40,418:ERROR :WebContainer : 5: [1393347820418]API Security Violation. [system]: ApiHelper
2014-02-25 18:03:40,418:ERRORDTL:WebContainer : 5: [1393347820418]<?xml version="1.0" encoding="UTF-8"?>
<Errors>
<Error ErrorCode="YCP0428"
ErrorDescription="API Security Violation." ErrorRelatedMoreInfo="">
<Attribute Name="ErrorCode" Value="YCP0428"/>
<Attribute Name="ErrorDescription" Value="API Security Violation."/>
<Stack>com.yantra.yfc.util.YFCException&#xd;
[...]


The error would then be logged once or multiple times by ApiHelper. In addition, the same is logged once by the OOTB wrapper class (here InteropHttpServlet):


2014-02-25 18:03:41,324:ERROR :WebContainer : 5: YFS Exception while invoking api createOrder [system]: InteropHttpServlet
2014-02-25 18:03:41,324:ERROR :WebContainer : 5: [1393347821324] API Security Violation. [system]: InteropHttpServlet
2014-02-25 18:03:41,324:ERRORDTL:WebContainer : 5: [1393347821324]<?xml version="1.0" encoding="UTF-8"?>
<Errors>
<Error ErrorCode="YCP0428"
ErrorDescription="API Security Violation."
ErrorRelatedMoreInfo="" ErrorUniqueExceptionId="9.155.214.16013933478212780000000000043">
<Attribute Name="ErrorCode" Value="YCP0428"/>
<Attribute Name="ErrorDescription" Value="API Security Violation."/>
<Attribute Name="UserExit" Value="yfs.ue.beforeCreateOrder.class"/>
<Error ErrorCode="com.yantra.yfs.japi.YFSException"
[...]

In this scenario, there are one or multiple services which invoke custom code. They are modeled as an extended API. The code then in turn invokes another custom service or API, for example:

public class MyService implements YIFCustomApi{ public Document invoke (YFSEnvironment env, Document inDoc) throws YIFClientCreationException, YFSException, RemoteException{ YIFApi api = YIFClientFactory.getInstance().getLocalApi(); Document out = api.executeFlow(env, "AnotherService", inDoc); return out; } }

Using api.executeFlow() or api.<api_name>() (e.g. api.findInventory()) will involve the additional ApiHelper wrapper. Assuming that the following invocations are done in one transaction boundary:



- MyService1 calls api.executeFlow() for MyService2
- MyService2 calls api.executeFlow() for MyService3
- MyService3 calls api.findInventory()
- findInventory throws an error

This will cause 3 repeating error messages logged by ApiHelper, since there were 2 invocations of the services MyService2 and MyService3 and one invocation of the findInventory API using the YIFApi object.

Resolving The Problem

The solution is to change the design of how APIs and services are invoked in a custom flow.

Use the Composite Service transport node instead of the extended API transport node when calling additional services. Also, use the standard API transport node instead of the extended API transport when invoking APIs. For example, the following service:

Start -> API (extended) -> End

with the API calling another service and the findInventory API internally, becomes:

Start -> Composite Service -> API (findInventory) -> End

It is best practice to keep the invocation of sub components as modular as possible. Calling sub components from an extended API is not optimal since the entire code would have to be changed/replaced if the service or API to be called was changed.

Using Composite Service and standard APIs, the flow is kept modular and changes can be implemented more easily. Also, this will avoid the additional invocation of the ApiHelper wrapper.

[{"Product":{"code":"SS6PEW","label":"Sterling Order Management"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Component":"Extensions","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All","Edition":"","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]

Document Information

Modified date:
16 June 2018

UID

swg21671460