My Products
Help
gerrit_deglee
CONTRIBUTOR **

http 500 error when using journaltransaction endpoint

by gerrit_deglee

We're having problems with the initial load of journaltransaction for a new customer of ours.

We're trying to load period 202101 and it fails on pagenumber 30

 

https://integration.visma.net/API/controller/api/v2/journaltransaction?pageNumber=30&periodId=202101...

 

The error is http 500 internal server error. We try this three times and then give up. We did see timeouts in pages 17, 23, 25 and 27, but retrying resolved those.

This is for ippcompany id 3001421.

 

Thanks,

Gerrit

11 REPLIES 11
Accepted solution
Yıldırım
VISMA

by Yıldırım

Hello,

 

there is a case that has been planned to be implemented in Visma.net Financials API updates for version 8.74.0 (November 2021)

which is expected to improve the performance of the V2 - Journal Transaction Endpoint. 

gerrit_deglee
CONTRIBUTOR **

by gerrit_deglee

Hi Yildrim,

 

If I look at the version number in Swagger, this is now implemented right? We do not see an improvement yet.

 

Thanks,

Gerrit

Yıldırım
VISMA

by Yıldırım (Updated ‎17-11-2021 14:49 by Yıldırım VISMA )

Hello Gerrit, 

releases can be followed in the "News" section also for sure by checking the swagger version tag. We've reviewed the company-id: 3001421 and we've seen that the new query structure wasn't activated for that company, it has now been invoked so that could you please try again ? 

 

Also noticed that in your query,

  •  "LastModifiedDateTime" value is 1900-01-01. This should be used with a date that matching with the data to narrow the scope of the data.
  • And It is missing the "LastModifiedDateTimeCondition" parameter.

 

 

https://integration.visma.net/API/controller/api/v2/journaltransaction?pageNumber=30&periodId=202101&lastModifiedDateTime=1900-01-01&releasedBatch=true&pageSize=1000

 

 

 

"...ModifiedDateTime" parameters should always be used together with "...ModifiedDateTimeCondition".

 

> GET

https://integration.visma.net/API/controller/api/v1/GeneralLedgerTransactions?
lastModifiedDateTime=2021-09-10&  (YYYY-MM-DD)

 

 

lastModifiedDateTimeCondition=%3E

 

 

Supported comparative operators for "DateTimeCondition"  (Those should be URL encoded in the query)
> (%3E)
< (%3C)
<= (%3C%3D)
>= (%3E%3D) 

gerrit_deglee
CONTRIBUTOR **

by gerrit_deglee

Thanks Yildrim, that seems to have helped! I don't see the LastModifiedDateTimeCondition parameter in Swagger for this endpoint?

Yıldırım
VISMA

by Yıldırım

Thanks for letting us know Gerrit 🙂 Sorry, I've mistaken with "GeneralLedgerTransactions" so in that case please also remove the lastmodifieddatetime from your Journal Transaction V2 query.

gerrit_deglee
CONTRIBUTOR **

by gerrit_deglee

Now you are confusing me. The LastModifiedDateTime is in the swagger specification for this endpoint. Just not the condition.

Yıldırım
VISMA

by Yıldırım (Updated ‎17-11-2021 15:17 by Yıldırım VISMA )

The usage of the "LastModifiedDateTime" parameter exposed in the Journal Transaction V2 is different from others. So there is no "LastModifiedDateTimeCondition" and it's set ">=" by default when the parameter used.

 

2021-11-17 15_10_21-Window.png
This is Mandatory if ‘PeriodId’ is not provided. In your case, you've provided the PeriodId, so you can remove the "LastModifiedDateTime" parameter.

gerrit_deglee
CONTRIBUTOR **

by gerrit_deglee

Any news on this?

Hi,

We are looking into it. We'll get back to you. 

by Magnus Johnsen

Hi,

Does always fail on page 30 or are you always trying in sequence?

Could you please try to just get that page via for example Postman or Swagger?

 

If this still fails we might need to investigate if there is anything wrong in the database. 

gerrit_deglee
CONTRIBUTOR **

Page 30 does fail in Postman as well (after a very long wait). The first few pages are fast, but they seem to be getting slower  and slower, until they time out. I don't think it is always page 30, but as I said, if I try just that page in Postman, it does fail.

Thanks