'XPRIM_HttpRequest.doPOST' JSON nesting?

[zigzigzig]

Hello all,

I'm attempting to POST with a JSON payload. The structure of the JSON is critical as its being used to create a searchable index. Thus far i've failed to get any successful responses, and when I look at the request in Fiddler, it seems like my JSON object has been nested within another objects. I'm using the .doPost( url ) syntax pulled straight from the docs.

what I wanted:
{"value":[{"@search.action":"upload","id":"1","StoreFrontId":"8","ItemCode":"0032","ItemCategory":[]}]}

what I got:

Inkedjson_formatting_vlweb_LI.jpg (638.73 KiB) Viewed 11730 times

This simply won't do. What am I missing here?

thanks,
- zzz

[tsupartono]

Hi,
I'm assuming that you were just testing it and were trying to see the value of the JSON string by putting that in the LANSA field W_JSONTXT? The WAM standard response would include the field type & value, where the value would have property name "value", so that's why it looks like your JSON is nested inside another JSON. But I think your JSON string is correct.

Can you post your RDMLX that sets up the XPRIM_HttpRequest?

If you'd rather not post the source code here, please send those to LANSA Support (lansasupport@lansa.com.au)

[zigzigzig]

I'd be happy to:

Define_Com Class(#XPRIM_HttpRequest) Name(#request)
Define_Com Class(#XPRIM_UriBuilder) Name(#Url)

#Url.SetScheme( 'https' )
#Url.SetHost( 'backnine.search.windows.net' )
#Url.SetPath( '/indexes/search/docs/index?api-version=2016-09-01' )
#request.Options.AddHeader Name("content-type") Value("application/json")
#request.options.addheader Name("api-key") Value("_________________________________")
#request.Content.AddJson( #oJson )
#request.DoPost Url(#Url)

This is all done in V14 sp1 with EPC 141050 applied.
Thanks!

- zzz

[zigzigzig]

Nevermind! What I was looking at in fiddler is the Webpage communicating with the server module not with the POST request in question. The issue with the 400 error i'm getting still persists, but the scope of the cause (might it be human error? *gasp*) is unknown as of yet so as it stands this issue is a dead end for now.

[tsupartono]

There is currently a known issue with the XPRIM_HttpRequest where the "Content-Type" is sent incorrectly as "application/json; charset=utf-8" instead of just "application/json". This could possibly be the issue. Some servers are more strict than other in validating incoming requests. Contact LANSA Support to see if you can get a patch for testing.

[Joop]

There is currently a known issue with the XPRIM_HttpRequest where the "Content-Type" is sent incorrectly as "application/json; charset=utf-8" instead of just "application/json". This could possibly be the issue. Some servers are more strict than other in validating incoming requests. Contact LANSA Support to see if you can get a patch for testing.

Does anybody know if this issue has been resolved in Lansa V14.2?

[BrendanB]

Joop,

I believe it has been fixed so that:

#request.Options.AddHeader Name("content-type") Value("application/json")

will override the default value of "application/json; charset=utf-8"

you may want to build the json payload as:

define_com class(#xprim_json) name(#JsonPayload)

#JsonPayload.text := #oJson

NOTE: i know this works at version 14.2 EPC142030 and above... so I would guess it depends on which EPC you use.

Please be aware that we are now at EPC150040 (Version 15), so you should really upgrade to that (and it definately will work at version 15).

Brendan.

[Joop]

Thanks Brendan!

We are indeed in the process of upgrading to Lansa 15. Test environment is already set up.