Hello Netanel, 

Nice framework you've provided, thanks.

I am wondering if it would be of any help to my case: I have used the Studio SOAP wizard to generate some webservice client classes and amongst those classes:

Class RMH.SOAP.s0.Output Extends (%Persistent, %XML.Adaptor) [ ProcedureBlock, SqlTableName = _Output ] {
...
Property Value As %GlobalCharacterStream(XMLNAME = "Value");

And the caller looks like

Class RMH.SOAP.SoapTreeSoap Extends %SOAP.WebClient [ ProcedureBlock ] {
...
Method Run...(Tree As %String, Inputs As %String, Debug As %Integer) As RMH.SOAP.s0.Output 

We do run a daily purge in all of our productions, but I noticed that some globals aren't being taken into consideration. The global related to the class above is occupying 8GB worth of data and its size isn't reduced after the daily purge take place (it uses the ensemble base class Ens.Util.Tasks.PurgeActivityData)

When I checked the global contents, I could definitely spot very old data... so that reinforces my assumption. Could the delete helper take care of this scenario? Or should I develop custom classes for the purge process?

Any help is appreciated.

Many thanks!

Hello Netanel, 

Nice framework you've provided, thanks.

I am wondering if it would be of any help to my case: I have used the Studio SOAP wizard to generate some webservice client classes and amongst those classes:

Class RMH.SOAP.s0.Output Extends (%Persistent, %XML.Adaptor) [ ProcedureBlock, SqlTableName = _Output ] {
...
Property Value As %GlobalCharacterStream(XMLNAME = "Value");

And the caller looks like

Class RMH.SOAP.SoapTreeSoap Extends %SOAP.WebClient [ ProcedureBlock ] {
...
Method Run...(Tree As %String, Inputs As %String, Debug As %Integer) As RMH.SOAP.s0.Output 

We do run a daily purge in all of our productions, but I noticed that some globals aren't being taken into consideration. The global related to the class above is occupying 8GB worth of data and its size isn't reduced after the daily purge take place (it uses the ensemble base class Ens.Util.Tasks.PurgeActivityData)

When I checked the global contents, I could definitely spot very old data... so that reinforces my assumption. Could the delete helper take care of this scenario? Or should I develop custom classes for the purge process?

Any help is appreciated.

Many thanks!

Hi there Marc,

Do you know whether is there anything to perform the opposite (convert an object into a xml string)?

E.g: 

Class BaseClass.Harvest Extends (%SerialObject, %XML.Adaptor) [ ProcedureBlock ]
{
Parameter ELEMENTQUALIFIED = 1;
...
Property Number As %String(MAXLEN = "", XMLNAME = "Number");
Property PatientNumber As %String(MAXLEN = "", XMLNAME = "PatientNumber");
...

Outcome would be:

<xml>
<Harvest>

   <Number></Number>
   <PatientNumber></PatientNumber>
...

Many thanks

Hi there Sean,

Do you know whether is there anything to perform the opposite (convert an object into a xml string)?

E.g: 

Class BaseClass.Harvest Extends (%SerialObject, %XML.Adaptor) [ ProcedureBlock ]
{
Parameter ELEMENTQUALIFIED = 1;
...
Property Number As %String(MAXLEN = "", XMLNAME = "Number");
Property PatientNumber As %String(MAXLEN = "", XMLNAME = "PatientNumber");
...

Outcome would be:

<xml>
<Harvest>

   <Number></Number>
   <PatientNumber></PatientNumber>
...

Many thanks

Hello Carlos,

These settings are a tad confusing because if not set up properly, can cause overlapping and, in my opinion, this is something the management portal should be able to validate and raise the error on the UI side.

In your case, the failure timeout is throwing this due to the fact that its value is lower than the Response Timeout and it shouldn't. 

Practically speaking: the operation will give up retrying after 15s. If the Response timeout is 30s, 15s has gone already (Failure Timeout triggers before the response comes), so logically you need a value here at least greater (double the Response timeout may be ideal).

This is the reason why you probably get the message saying that the Failure timeout exceeded. Furthermore, this should be combined along with the Retry interval, otherwise it will overlap its functioning.

Hi Julian,

Thanks for your time.

OK then, but removing the return doesn't affect anything at all. I actually put it there while testing to see if it would impact somehow.

The test that I've just did was getting rid of the return (keeping the order of the "whens") and the message only hit the 1 when target (in this case "ManageEDM". I then switched the order and it only hit the "ManageRIS". See below

Hi Jan,

Thanks but I want to follow what the deployment tool is advising me to, include everything I need through the management portal export tool. What is the solution in this case then?

Because we know that the export tool has a very poor interface that doesn't allow me to select more than 1 file, hence I need to to stick to creating a "project file" if I want to include a group of custom files for example, but it doesn't seem possible.

I don't really see a way out.

Hello Tani,

Thanks for sharing this useful information.

I have the feeling that Intersystems could somehow improve the tool in terms of validating and not allowing timeouts overlapping each other, if you understand what I'm saying.

It is a very common mistake people make when configuring these timeouts and sometimes they end up not enjoying the real benefits they can offer.

I am now very confused while trying to put in context what you described in your article (related to webservices) along with the TCP connection world, because it has got, additionally to the timeouts you've mentioned:

Stay Connected
Connect Timeout
Reconnect Retry
Read Timeout

For example, the reconnect retry sounds very close to the purpose of the Retry Interval, so I am not too confident on how to set these guys up.

Are you able to give me a helping hand?

Thanks