07-17-2014 12:34 PM
hello everyone. I have a webservice that I am trying to pass an xml into using Proc SOap. The problem is one of the elements is too long for SAS to work in Proc soap.
Basically I originally had an element that was ~5,000 chars in length. When sas write it out to an XMl file, it will add "line feeds" at the 256 position (since lrecl is defaulted to 256).
The issue is, this one string is actually a delimited list of multiple values, delimited by the value @#. Apparently some of the line breaks occured between the @ and # value of a delimiter, so the application I am passing into breaks when trying to split this line string.
To fix this problem, I changed the LRECL to 10,000, and when looking at the file, there is no longer any line breaks. HOWEVER when trying to run proc soap, I get the error
[Fatal Error] :1:6644: The element type "XX" must be terminated by the matching
IF I add the line breaks back in (manually) the proc soap works. It looks like proc soap has a line limit on the XML files it reads in and passes to applications. Does anyone know a way to fix this issue?
Before anyone asks, I don't think this field should be one giant string.. It's actually 100 different "exceptions" concatenated into one string, however our dev development team has mandated this as required, therefore it HAS to be one string with these given delimiters.
Given that i'm not sure how to fix this problem, any ideas?
07-24-2014 02:39 PM
I know the default lrecl was some time 255 latest version sometimes 32K the default of that is in the SAS config. SAS(R) 9.2 Language Reference: Dictionary, Fourth Edition
There are some paper mentioning proc soap. http://support.sas.com/resources/papers/proceedings12/119-2012.pdf
Base SAS(R) 9.2 Procedures Guide there is note on streamlf required with VMS. I wonder why
Did you ask TS (track number?) already.
08-14-2014 10:12 AM
I am actually not sure if this is a SAS issue or an issue in the web service we are calling.
I CAN change the LRECL of the xml file to 32000 (and when you open it lines ARE NOT wrapped). However hwen I call proc soap it says "tag not closed" error, as one of the tags is so long on the line that sas is not recognizing the ending tag for it.
I'm actually not sure if SAS isnt' recognizing the ending tag, or if the web service can't take lines that long.... Does anyone know how I would check this?
08-15-2014 03:43 PM
To further complicate this problem, it appears that application that is accepting the XML files is actually reading the line breaks that sas is writing when creating the XML files.
Has anyone had any kind of luck passing strings > 256 length from SAS to a web-service using proc soap? Everything i'm seeing seems to basically imply it can't be done.
You can't cahnge the LRECL of the xml file you create to allow for longer strings because sas throws a "opening tag needs ending matching tag" error, and the system will read in the line feeds that sas creates when outputting the xml file....
02-12-2015 06:18 PM
. I did end up fixing this problem. It turns out that even if your XML files have line breaks in them, the call to Proc soap WILL STILL WORK. Even if the line breaks occur between delimiter values.
HOWEVER: If you take the same XML file, and try to load it into the application through something like "SOAP UI" it will fail. SOAP UI is not 'smart enough' to ignore the line breaks, but for whatever reason SAS is.
HOWEVER: When the string gets into the application, it WILL have the line breaks. So you will have to have the peson who controls the application parse out the line breaks from the string, thus 'fixing' the problem.
I still don't know why SAS can't set the LRECL of a xml file to >2,000 without Proc soap failing on it. I think this is an inherenty deficiency in SAS.
Update: In the end, due to this and many other concerns, we actually changed the way the system worked. We were able to talk to our App developer, and grant my account access to the database tables. I now simply write my calls to the tables, and only send the "loan identifier" through the proc soap, telling the application which loan to grab from the database.
It's a much simpler solution, and the route I would have done originally if I could have, but since I didn't control the app it was never on the table.... Until the app developer changed his mind.
Hope that helps