Caché String limitation and Web Services

85 views
Skip to first unread message

Andrew Raastad

unread,
Dec 21, 2009, 12:28:40 PM12/21/09
to intersystems...@googlegroups.com
Allow me to preface this by saying I am *not* a Caché guru here, I deal with the .Net side of things....

We have a scenario where our application (Caché-based) needs to consume a SOAP Web Service which is written in .Net.  The .Net Web Service is consumed in the Caché code by proxy classes created from the Caché Studio add-in tool "SOAP Client Wizard". The Web Service simply returns a string (the size/length of which is unknown until after it is returned), and this is what the proxy classes are built as. However, this can be a problem if the amount of data that is returned is larger than 32KB, which is the limit for a String in Caché.

What is the best way to deal with this situation? Is there a different type I should have the .Net Web Service return the data? Can the proxy classes on the Caché side be altered by hand to use Stream instead of String?

Is there anyone here who has run into this situation? Any suggestions on the best way to solve this?

Thanks

-- Andrew


OldMster

unread,
Dec 21, 2009, 2:00:10 PM12/21/09
to intersystems.public.cache
The 32kb limit on strings in Cache has been expanded in recent
versions, but the capability is disabled by default.
If you are on one of the versions with long string support (5.2?
2007.1? somewhere around there), there will be an option
in the memory and startup configuration setting to enable long string
support. in the earliest implementations, it was about 1 megabyte per
string, and now I believe it is up to 3 megabytes.

Mark

htg

unread,
Dec 21, 2009, 2:49:08 PM12/21/09
to intersystems.public.cache
As Mark pointed out correctly the 32k limit is still
in place and long strings (~3.6 MB) have to be enabled
manually in te system configuration.

The deeper reason for the issue is based in WSDL.
WSDL deriving from XML schema and none of them tell you
anything about size.
So it's up to the developper to adapt the target
structure manually.
If you can't predict the size of your string you better change
the type from %String (limited to 32k or 3.6 MB) to an
%Stream type (GlobalBinary... FileBinary... ) unlimitted in size.
The wizard generating your proxy classe has no chance
to decide on your concrete situation.


Andrew Raastad

unread,
Dec 21, 2009, 2:59:07 PM12/21/09
to intersystems...@googlegroups.com
Mark,

I passed along your reply and this is the response:

"I’m aware of the long string support but most of our clients don’t have that enabled and we would need to do some testing before enabling it.  The long string support would set a much higher limit to the size but not necessarily high enough and not nearly as high as a stream.  So I’d still like to get a stream solution."

So, while it appears there is nothing wrong, per se, with what you suggest, it just requires too much changes to systems already in place to make it a viable solution.  So I am back to looking for a way to solve our issue without having to modify the core Caché system.

-- Andrew



--
List: http://groups.google.com/group/intersystems-public-cache
Devcon: March 21 - 24, Orlando, Fl.



--
My new philosophy!
Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting "...holy shit...what a ride!"

Andrew Raastad

unread,
Dec 21, 2009, 3:02:30 PM12/21/09
to intersystems...@googlegroups.com
htg,

Your response seems to be more in line with what our Caché guys want... a Stream solution.  So, is this something I effect by altering the data type used in the .Net Web Service, or is done on the Caché side by manually altering the wizard generated proxy classes? If the former, what data type do you suggest for Caché to "see" it correctly? If the latter, what changes should be made to alter it from a String-based class to a Stream-based class that will still work with the Web Service?

-- Andrew



--
List: http://groups.google.com/group/intersystems-public-cache
Devcon: March 21 - 24, Orlando, Fl.

htg

unread,
Dec 21, 2009, 3:48:11 PM12/21/09
to intersystems.public.cache
Hi Andrew,

My suggestion:
don't change anything at .NET end.
It won't change the generated the WSDL

Just change the proxy class on Caché. MANUALLY.
That should be enough.
Any SOAP-Body arrives in Caché as an XMLstream.
It is then correlated with the proxy object and loaded.
That correlation takes care of loading any conversion %String or
%Stream
Have your Caché guys taking a try with importing
any XML document. The difference to SOAP is just the transport.

Benjamin Spead

unread,
Dec 21, 2009, 2:01:45 PM12/21/09
to intersystems...@googlegroups.com
Try changing %String to %GlobalCharacterStream in the proxy class signature. This should allow you to save as much data as you want.

Mark

--

Renato Fagalde

unread,
Dec 22, 2009, 7:49:27 AM12/22/09
to intersystems...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages