Hi,
I am using an API OIS017MI.LstPriceList in the MEC map which return value sometimes and sometimes not.
In all the cases M3 data remains unchanged. What could be the reason for this behaviour any idea?
Can you attach a screenshot of your API mapping?
Jonathan
Can you please make sure your input values are populated correctly before calling the API.
You can put a Java Code section before the call and add statements like below to check each input variable (these show in the Log afterwards): cat.info(strUUID + "[:] chkInputValues PRRF = " + PRRF);
/Rene
I hope you have cleared the API Cache.
Thanks for the response guys. This is the place where i am facing the issue. We are having all the input values at the right place. There is no issue with the API input. Issue is with the API response. I am trying to retrieve 'FROM Date' and 'TO Date' from this API, and passing this value as input to OIS017MI.GetBasePrice to retrieve the Sales Price.
As per the Debug log this API OIS017MI.LstPriceList is not working as always. Sometimes it is producing the right results and sometimes not. In all the cases M3 remains the same.
For ex: When i drop the same .rcv as input to MEC multiple times manually, In few cases I am getting the right Sales Price Output, And in few cases i am not getting the Output.
too basic question from me . Is the price list API request done by same user with the same API or different users ?
What's the reason for providing the NFTR Input Variable?
Sometimes we observed the API checks into users set up in M3 and then from the authority and others it may cause error.
I am passing the NFTR value as 2, as i am passing two inputs to the API price list and Currency and need to filter my output based on this two input. Without this NFTR parameter, this API will fetch all the data from OPRICH.
All the API request are done by the Global API user for which we don't have any restriction.
If it is possible for you to restart the MEC server, then please try to disable the API Pooling from the MEC Server grid properties and restart the MEC server after.
I had experienced problems with OIS100MI locking orders sometimes because of the API Pooling, after I disabled it, the issue was "fixed".
Hi Jonathan,
What is the impact on M3 when we turn-off the API Pooling?
It has been ON since beginning.
Yes, it's the default. You can see in M3API that there are always at least two running APIs, that's the API pooling. I see two advantages in using pooling:
1. Without pooling, every API call will create a new connection to M3, which can take around 50-500ms, and with pooling enabled that less than 50ms, because the connection already exist.
2. The M3API subsystem will never shutdown because there are always API jobs - however, that sometimes is disadvantage...
I believe that if your problem is "fixed" with pooling disabled, then you can open an incident in Infor regarding this specific API behavior. If it's not fixed, then you can re-enable the pooling and check other options...
That's not a MEC problem - confirm user access.
