Hitting max number of requests

[Florian Haase]

Hi,

we have an integration here based on discount-agreements. The customer creates a lot of agreements with a connection between customergroup or customer to inventory items.

In the integration to the 3. party system Visma.Net is declared as the mastersystem. We need to refresh the discount agreements completely in the 3. party system once a night, otherwise we run into problems with deleted agreements or deleted connections. (changes and new ones we can catch, but not deleted ones (thats actually the first problem)).

First we thought that the minor part of agreements is based on item-connections (instead of item-group), but now I see thats actually the major part. That means nearly each inventory-item has any connection to one or more of the agreements. Since we need the External InventoryID (stored in the attributes on the inventory-Items) I run a get call now on each involved inventory-Item to get the external ID. (we get each inventory just once even it is used on several discount agreements since we store the result in the memory and reuse it). That causes in the end  an overflow in max number of requests (at least in some situations).

It seams to be better to get the whole inventory database from Visma.Net first with some fewer calls. We did not do this by design first, because the inventory endpoint is so extremly slow but that would of course reduce the number of calls. We will get some more inventories than needed but that's maybe the only way to get around the problem?

I start to wonder a bit if it would be better to store the internal Visma-Inventory ID in the third-party system and get the whole inventory list from there instead. I guess that would be many times faster than asking the Visma.Net API or do you have any other suggestions?

Florian

[Yıldırım]

---

@Florian Haase wrote:

First we thought that the minor part of agreements is based on item-connections (instead of item-group), but now I see thats actually the major part. That means nearly each inventory-item has any connection to one or more of the agreements. Since we need the External InventoryID (stored in the attributes on the inventory-Items) I run a get call now on each involved inventory-Item to get the external ID. (we get each inventory just once even it is used on several discount agreements since we store the result in the memory and reuse it). That causes in the end  an overflow in max number of requests (at least in some situations).

It seams to be better to get the whole inventory database from Visma.Net first with some fewer calls. We did not do this by design first, because the inventory endpoint is so extremly slow but that would of course reduce the number of calls. We will get some more inventories than needed but that's maybe the only way to get around the problem?

If the External-ID is static once the discount setup is done, storing all the historical data in your end would be definitely more efficient. In this way you can fetch the new records with "createdDateTime" or "lastmodifieddatetime" filters targeting to retrieve new inventories or only if there are any changes on the item. 

Alternatively, you can check the New Sales Order API Service that GET-Inventory Endpoint is available and should perform better.  <https://salesorder.visma.net/swagger/index.html>

Should return the inventory with the attribute values assigned.

https://salesorder.visma.net/api/v3/Inventory?expand=Attribute

Getting started with the first neXtGen service: Visma.net ERP Sales Order API

[Magnus Johnsen]

The neXtGen salesOrder inventory endpoint is a lot faster in our example company, for the data set we have in our test company it's about 2-4 times faster, so it might be a solution that would be worth having a look at for you. 

We are also working on improvements for the current Inventory endpoint, unfortunately the latest improvement had caused some issues and needed to be rolled back for now. 

[Magnus Johnsen]

Hi,

What is your current workflow? 

Is there any information you are looking for in the inventory endpoint except, Internal ID -> External ID?

If not, storing the connection might be a good idea, and then just updating that record with newly added inventory items.

[Florian Haase]

Yes thats right.

We would get a bit closer the solution if we could get the InventoryNumber in the discount Endpoint in addition of the ID. I'm not sure that storing a match table is a good design - than we have one more source for possible errors. 

But just to get rid of the problem I change it now to get the whole inventory-register with filter on integrated inventory Items. When I only expand the attributes and nothing else it takes about 3 minutes for about 3000 inventories. That was acceptable here and now. We also looked at the new SalesOrder API - Could this be a possible solution - is it much faster?

Florian