User Answers

To add a new header, you need to create a subclass of %SOAP.Header with the property you need. Once you have that then you can add it to the appropriate array e.g.

S myheader = ##class(MyNewHeader).%New()

S myheader.mykeyproperty = <myvalue>

D myservice.HeadersOut.SetAt(myheader,"MyNewHeader")


This is assuming the header is not automatically generated from the XML schema.

Since you're using ObjectScript you should get the value from the list using something like $LISTGET(CList,i). That should return the correct value without control chars. 

If you still want to use $PIECE then SET CListString = $LISTTOSTRING(CList) and then use the $PIECE on the CListString

I like them in the following order:

1) Class Queries

2) Dynamic Queries

3) Embedded SQL

There was a time when Embedded SQL were way faster than dynamic queries, however I think that's not that different anymore. The readability provided by dynamic queries (especially for people new to Cache) outweighs the performance embedded SQL could provide. Of course each situation is different and maybe your application might benefit greatly from that extra performance.

For Cache/IRIS, the JOURNAL files would be the closest option to CDC. There isn't any "generic" product out there that can read and publish the content on journal files for things like streaming or other uses. You can certainly write something to read and publish/stream the changes but it'll be a customized option. 

Cache/IRIS can do it internally for Cache-to-Cache sync/mirroring so it is possible to follow the same logic for other uses. Maybe check with Intersytems if they have had request lake this before. Either they already have a utility or can help you build one. 

Not sure exactly what you're trying to do or what problem  you're exactly facing (more details would be helpful) but, assuming you're trying to handle the soap body yourself instead of what the wizard generated then you can create a method to create the body and add the name to the WriteSOAPBodyMethod  property of the client class. It's not recommended to call Cache internal methods in your code. It's better to use any provided "hooks" if available.

1) The reasons for using both together are purely based on your application's need and design. Some design patterns specify desired visibility of methods for example.

The easiest way would be to change the definition from list to array. But if you can't do that the next easier thing is to change the STORAGEDEFAULT parameter to 'array'.  Both options will project the collection as a separate SQL table that you can join with.