#XPRIM_HttpRequest

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
mm1
Posts: 5
Joined: Fri Feb 16, 2018 11:20 am

#XPRIM_HttpRequest

Post by mm1 » Fri Feb 16, 2018 11:32 am

Hello,

I have used #XPRIM_HttpRequest to post some parameters and a file:

#ContentInfo.Clear
#ContentInfo.MediaType := '*BLANK'
#ContentInfo.ItemName := 'EBSYSUTC'
#Request.Content.AddString Value(#UTCOS) Contentinfo(#ContentInfo)

#ContentInfo.Clear
#ContentInfo.ContentDispositionFileName := #JOBTMPNAM
#ContentInfo.ItemName := 'EBMONJD'
#Request.Content.AddFile Path(#EBMONJOB) Contentinfo(#ContentInfo)

I created the CSV file as CCSID 819 (ASCII) but when I receive it via a WAM it is CCSID 37 (EBCIDIC). I can view it va WRKLNK and via Windows explorer but I want to read the file via STM_FILE_OPEN.

When I do this, I just get rubbish coming in.

The request.body.log shows the file as "Content-Type: application/octet-stream".

Do I need to specify a media type?
#ContentInfo.MediaType := ????

Or what do I need to do to read the stream file?

Thank you.

tsupartono
Posts: 74
Joined: Wed Jan 25, 2017 11:12 am

Re: #XPRIM_HttpRequest

Post by tsupartono » Fri Feb 16, 2018 12:42 pm

Hi Muir,

I don't believe that the WAM runtime checks the received Content-Type, so in this case the content would still be encoded in ASCII, but it seems that CCSID 37 was (incorrecty) applied when the file is created by the WAM runtime.

Changing the Content-Type in the HTTP request is unlikely to have the desired effect, as the WAM runtime would just ignore that and creates the file as binary anyway.

As you have suggested, the solution would be in how you read the file.
Instead of reading the file using STM_FILE_OPEN, try using the following:

http://docs.lansa.com/14/en/lansa015/in ... 0_0710.htm

The XPRIM_File.ReadAllText reads the content of the file as UTF-8 (since your file is ASCII-encoded, that should be fine).

mm1
Posts: 5
Joined: Fri Feb 16, 2018 11:20 am

Re: #XPRIM_HttpRequest

Post by mm1 » Fri Feb 16, 2018 2:49 pm

Thanks for the response. I can see the text when I use ReadAllText however there is a 64k restriction which is not big enough for some of my files.

The file is a comma delimited file with CRLF and I need to read the file record at a time.

The doc for STM_FILE_OPEN says that if you use the "text" open option (which I do) "The data will be converted between the code page of the job and the code page of the file.' so this should work but does not.

So I don't really know how to read the data out of this file.

tsupartono
Posts: 74
Joined: Wed Jan 25, 2017 11:12 am

Re: #XPRIM_HttpRequest

Post by tsupartono » Fri Feb 16, 2018 3:01 pm

If you have to use STM_FILE_OPEN, then I think the best way is to determine first how to get the receiving WAM runtime to create the file with the correct CCSID (ie, 819 instead of 37). If the file is created with a correct CCSID, based on the way you describe it, STM_FILE should be able to read the file correctly.

My suggestion would be to send this to LANSA Support first to see if there is a way to get the WAM runtime to create the file with the correct CCSID. As a last resort, we most likely can add the equivalent of STM_FILE_OPEN to the RDMLX Extended Library that will let you read the comma separated files in UTF-8.

soa
Posts: 287
Joined: Mon Dec 07, 2015 3:15 pm

Re: #XPRIM_HttpRequest

Post by soa » Fri Feb 16, 2018 3:25 pm

Sounds to me like the WAM is creating the file with a CCSID of 37 but not translating the contents so they appear as junk,

mm1
Posts: 5
Joined: Fri Feb 16, 2018 11:20 am

Re: #XPRIM_HttpRequest

Post by mm1 » Fri Feb 16, 2018 3:50 pm

Thanks.

As I stated in my original post, my function (not a WAM) creates the CSV file as CCSID 819 using:

Use Builtin(STM_FILE_OPEN) With_Args(#EBMONJOB 'Write Text LineTerminator=CRLF CodePage=819' A)

When I look at t in the IFS (WRKLNK) the generated file CCSID is 819, which is correct.

Once I have received that file by:

Define_Com Class(#XPRIM_File) Name(#File)

#File := #EBMONJD
If Cond(#File.Exists)
#TMPPTHNAM := #EBMONJD.FileName
// view file in IFS TMPPTHNAM
Endif

The CCSID is now 37. So some where in the code above it was received as CCSID 819 and ended up CCSID 37.

Muir

tsupartono
Posts: 74
Joined: Wed Jan 25, 2017 11:12 am

Re: #XPRIM_HttpRequest

Post by tsupartono » Fri Feb 16, 2018 4:07 pm

This code below does not actually receive or create the file - it's just a utility function to get file size etc.

Code: Select all

#File := #EBMONJD
If Cond(#File.Exists)
#TMPPTHNAM := #EBMONJD.FileName
// view file in IFS TMPPTHNAM 
Endif
When you say that you receive the file, what's the mechanism?
Do you use server module, or WAM (ie, the target of your HTTP request)?

mm1
Posts: 5
Joined: Fri Feb 16, 2018 11:20 am

Re: #XPRIM_HttpRequest

Post by mm1 » Fri Feb 16, 2018 4:49 pm

The target of my HTTP Request is a WAM. The request.body.log shows:

--BgYlioDV53UFJGBk3RO1aCAfTSJKxFDO82bWgJ1aUTaSt6dl4IM5mpA91B6i5xQb
Content-Type: application/octet-stream
Content-Disposition: form-data; name="EBMONJD"; filename="eBOS Monitor Job Data Outbound EXAM1-V40.csv"

and in the WAM I have:

Web_Map For(*INPUT) Fields(#EBMONJD)
Web_Map For(*OUTPUT) Fields(#JOBPTHNAM)

The *OUTPUT JSON shows:
"fields":{
"JOBPTHNAM":{
"type":{
"t":"A",
"l":256
},
"value":"/LANSA_dc@pgmlib/run/web_upload/04b73109-41a9-44e5-9ade-d5a5bf283f26/eBOS Monitor Job Data Outbound EXAM1-V40.csv"
},

The file in JOBPTHNAM value is the one I move to a more permanent folder (MOV command) then I try to read and its the one with a CCSID of 37.

tsupartono
Posts: 74
Joined: Wed Jan 25, 2017 11:12 am

Re: #XPRIM_HttpRequest

Post by tsupartono » Fri Feb 16, 2018 5:01 pm

The WAM runtime (part of the LANSA runtime) creates a file automatically for you when you use BLOB field (EBMONJD) to receive data, and my believe is that the file is always created with a fixed CCSID (possibly the default CCSID for the user profile), instead of using the Content-Type to determine the correct CCSID.
This is happening before your RDMLX executes, so there is no way for you to control this. If you contact LANSA Support, they should be able to confirm/deny this (that the WAM runtime always create a temporary BLOB file with a fixed CCSID).

However, you also mention that you use MOV command to move the file? Are you talking about IBM operating system MOV command? The command has a parameter to change the CCSID of the file being moved, so probably you can change the CCSID back to 819 at the same time?

mm1
Posts: 5
Joined: Fri Feb 16, 2018 11:20 am

Re: #XPRIM_HttpRequest

Post by mm1 » Fri Feb 16, 2018 5:20 pm

I added TOCCSID(819) to the MOV command and it worked.

I appreciate a solution but I'm just worried this technique may be avoiding a bigger issue.

I'll think on it more over the weekend.

Thank you for your time and suggestions.

Muir

Post Reply