Solved: Inventory API: Slow performance

plh · ‎03-09-2020

Hi Visma,

Using the Inventory API endpoint, we experience slow responses. Worst case performance for single item >10 sec and best case is 0.5 sec. Average is 0.8 sec.

Having to display stock availability for an order with say 20 lines, will give us 20x0.8sec = 16 secs for retrieving stock alone. 😭

We've tested both direct inventory lookup and alternateID, performance numbers are equal.

(We're using alternateID on this customer because of url encoding bug in main inventory endpoint)

Suggestions:

- Can performance be improved

- Feature to select/filter what fields API should return

- Dedicated warehouseDetails/stock endpoint (we often query Inventory to get only stock availability, and discard rest of the data returned)

Workaround:

- Can we get stock counts from another endpoint faster? GL, Journal etc?

Magnus Johnsen · ‎04-09-2020

When you are talking about the URL encoding, what bug is it that you are experiencing?

plh · ‎04-09-2020

The customer has itemnumbers like: 01-210034_BK_30/32

Therefore using the Inventory to lookup single item would be

/API/controller/api/v1/inventory/ITEMNUMBER

In order to use the endpoint the itemnumber must be URL encoded in order to send the / char.

curl -H 'Authorization: Bearer XXX'  -H 'Accept: application/json'  -H 'ipp-company-id: 2086025' "https://integration.visma.net/API/controller/api/v1/inventory/01-210034_BK_30%2F32"

But this results in HTTP 404 error in API.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /API/controller/api/v1/inventory/01-210034_BK_30/32 was not found on this server.</p>
</body></html>

Magnus Johnsen · ‎04-09-2020

You should be able to use the base64Url encoding method we implemented earlier this year for all resource endpoints.

Where the resource ID would be, simply put the base64URL encoded value within b64().

Underscores are interpreted as segment delimiter / space in the resource name, and when you encode them with b64 space should be used instead of "_":

In your case the call would look like this:

/API/controller/api/v1/inventory/b64(b64(MDEtMjEwMDM0IEJLIDMwLzMy))

Please try this and let us know if this is causing you any issues.

The performance issue from yesterday seems to be under controll now and the calls should be working better today. We are still looking into the general performance of the inventory endpoint.

plh · ‎04-09-2020

Hi,

Using you base64 solution with replaced _ to spaces does not work.

Using your b64(MDEtMjEwMDM0IEJLIDMwLzMy):

curl -H 'Authorization: Bearer XXX'  -H 'Accept: application/json'  -H 'ipp-company-id: 2086025' "https://integration.visma.net/API/controller/api/v1/inventory/b64(MDEtMjEwMDM0IEJLIDMwLzMy)"

gives

{"message":"Inventory with number 01-210034 BK 30/32 could not be found"}

But keeping the _ before b64 encoding - b64(MDEtMjEwMDM0X0JLXzMwLzMy):

curl -H 'Authorization: Bearer XXX'  -H 'Accept: application/json'  -H 'ipp-company-id: 2086025' "https://integration.visma.net/API/controller/api/v1/inventory/b64(MDEtMjEwMDM0X0JLXzMwLzMy)"

does indeed work. 👍

----

Does not seem to have any impact on the performance figures, but this allows customer to delete all the dublicated data in their financials.

PS. After the update on incident, we dont see any improvement in timings. I can send export for all calls if you need.

Yıldırım · ‎04-09-2020

Underscore is being used as a segment delimiter in the Financials UI therefore end-user can not create a resource by using "_" .

Financials ERP UI replaces "space" chars with "_" when resourceID is shorter than the defined segment length therefore you should avoid to use underscore while creating resources via API.

Especially this misuse will be taken into consideration as a bug in API with POST operation. API should not allow using "_" for resource identifiers. This may lead wrongfully referenced inventories in the UI/ DB transactions.

When you POST an Inventory via API:

{
    "inventoryNumber": {
        "value": "01-210034_BK_30/32"
    },
    "type": {
        "value": "FinishedGoodItem"
    },
    "description": {
        "value": "Underscore usage via API"
    },
    "itemClass": {
        "value": "6"
    },
    "postingClass": {
        "value": "1"
    }

Financials UI (Underscore cannot be entered as ID char in the UI )

Then when you try to overwrite the same underscore used value manually on the UI by Update ID Action, system will replace these underscores with space char.

@plh wrote:
Does not seem to have any impact on the performance figures, but this allows customer to delete all the dublicated data in their financials.

PS. After the update on incident, we dont see any improvement in timings. I can send export for all calls if you need.

Please send these reports to <developersupport@visma.com>

plh · ‎04-09-2020

Hi Yildirim,

The visma consultant helped the customer change this underscore char in their Financials, because they already had 1000's of items with _ in the itemno.

So they changed the placeholder char to *

Magnus Johnsen · ‎03-09-2020

Hi,

Regarding the issue, could you please send us an email at developersupport@visma.com with your companyID and ClientID and we'll have a look at it.

When it comes to suggestions on improvement, please post it in the ideas part of the forum so that the development team can have a look at it.

Posting in ideas will apart from ensuring that the development team will see the request, open up for other users of the forum to vote on your suggestion.

The amount of votes that your suggestion has will affect the priority the affected development teams have on implementing your suggestion.

To make sure that it is implemented in the way that you are looking for, we kindly ask you to specify the business need as much as you can.

plh · ‎03-09-2020

Hi Magnus,

We are seeing the same performance figures on multiple companies.

I dont see ~1sek/item performance as an idea for improvement, this seems to be a (big) issue that needs attention.

Magnus Johnsen · ‎03-09-2020

Also to make clear, right now there is a incident at the moment, please follow it here: https://status.visma.com/incidents/4prq8jph2fx4

plh · ‎03-09-2020

Hi

This is not a slowness we're experiencing now, its a persistent issue with same performance figures for many months.

Magnus Johnsen · ‎03-09-2020

Hi,

As I mentioned, could you please send us an email with the details that I mentiond in the previous post so that we can have a look at it?

Thank you.

Regarding the items you posted under suggestions, as I mentioned, we would appreciate if you could post these under the ideas part of the forum so the development team can see it and add it to their backlog.

Thank you.

Inventory API: Slow performance

Useful pages

About Visma

Contact us

Follow us