Skip to main content
I am trying to connect with a 3rd party API (Visma API based on Swagger) and for some reason I can't seem to get an output from the HTTP connector. For testing purposes I insert the connector output into a text file but the file remains empty. This is the debug error message in the application after triggering the process flow:



code:
Unexpected character encountered while parsing value: A. Path '', line 0, position 0.


This suggests the connector output is empty which would explain why the file remains empty. If my assumption is correct then I don't understand why this happens. I have created the correct API call in the Insomnia application first and I get the expected json result:





(Don't worry about data sensitivity because the data comes from a test account.)



All the API call needs is a URL and these 5 headers (including a token). In SF I've set the parameters as follows:





With 5 headers as a single value containing 5 lines being:



code:
Accept: application/json
Accept-Encoding: gzip, deflate
Authorization: Bearer cb3987a4-ee55-4f31-acbc-************
ipp-company-id: 1599238
ipp-application-type: Visma.net Financials


The output of the HTTP connector goes into a parameter called json_output which in turn is used as data input in a write file connector. The text file used for output is accessible to the user account under which I run the application.



What could be causing the file to remain empty?
Hi Roland,



The input headers are currently only accepted in JSON format. You can find more about this in the docs.



However, I think it would be a great improvement to accept a newline and colon separated value as headers value as well. I'll raise this with the devs.
Thanks, Anne. Very useful information! I'll rewrite the header in json format and will post the outcome here.
I rewrote the header in json format and it works now. I did have to omit the Accept header because of this error message:



code:
The 'Accept' header must be modified using the appropriate property or method. Parameter name: name




Luckily the API works fine without it.

Hello Roland,

The accept header will now no longer be added to the normal headers, for it has a separate property to set the value for this. This also counts for Content-Length and Content-Type headers.

If you are interested you can see a list of all special headers here:
https://docs.microsoft.com/en-us/dotnet/api/system.net.webheadercollection.isrestricted?view=netframework-4.8

We now use that method to check if the given header can be set in a normal way or should be set with a separate property.

The next GUI release which will come the 3rd of March will contain this fix.

If you have any further questions please let me know.

Kind Regards,
Roel

Reply


Terms & ConditionsCookie settings