Thanks again Gertjan, your feedback continues to help refining the correct messaging on this.

Indeed I believe the wording in the documentation is, as you put it, "vague", on purpose - "Under certain conditions". The Continue I used to "trigger" the error (as you noticed, and reproduced) is "part of the picture" but not the whole picture, therefore instead of diving too deep into what is the exact sequence of events that might cause this (I tried not to either, just provided an example...), the reference is more "general".

I think also you arrived yourself at the understanding of what I was referring to when I said "not the best practice" when you mentioned - "A Continue inside a Scope, however, is never needed ... Perhaps I also did a Continue inside a Scope. In that case, it was a bug on my part."

So are scopes insides loops "totally forbidden"? No... the Documentation did not state that, just "Under certain conditions".

But - if someone encounters the error I pointed out - I hope they come to realize it's root cause is this structure, and that they have a direction for avoiding it (and probably arriving at a better flow as a consequence).

Now perhaps you are saying - well, instead of taking the scope out of the loop, just get rid of the Continue, that would really depend on the use-case, on the specifics of the process being implemented. Also, different people have different opinions on the "best way" to handle errors (in general in code; I've seen in another discussion you had some strong opinions about Try/Catch in code; and specifically using this mechanism within a BP), and some might argue that one general Scope for the whole BP is enough (or better) rather than having multiple ones in separate parts of the BP. But I think that's a topic for a different discussion... 

I'm happy to hear this has helped you Gertjan shed some light on the behavior you were experiencing.

Please note that this is not considered as a "bug" though, but rather as a (documented) "limitation".

And, as documented, and as you seem to indicate about your case, it is not too difficult to avoid/workaround.

Since I just came across already the 3rd customer of mine that has encountered this phenomena I figured I'd share what the manifestation of this limitation looks like, for the benefit of saving some time for the next person who runs into it, and "scratches their head" when they face that error, probably not immediately correlating it to the known issue I pointed out.

Note also (as this might have been your thread of thought, or of others who read through this), the issue here is not the simple technicality of the 50 character length limit of the related Property (which happens to be the call-stack of fault-handlers of a BP; as indicated in the error message; which I assume you could simply suggest extending to a larger capacity), but rather this is a "pointer" or an "opportunity" to raise the fact that this "design" or "structure" is not the "recommended" or "best practice" construct for a BP (to have a scope inside a loop).

So thanks also for the chance of clarifying this side of the topic.

After @John.Murray's gladdening announcement about the availability of the VSCode InterSystems Server Manager v2.0 the "Import Servers" functionality has another way to be called -

Click the ... (3 dots) on the top right corner of the InterSystems Tools pane, and you'll see the option below.

Totally agree.

Important Note -

Some classes - for example the built-in Business Process class (Ens.BusinessProcessBPL) - have already specific implementation of an %OnDelete method, and hence adding the DeleteHelper as a SuperClass would override the "default" %OnDelete that class might have (depending on the order of Inheritance defined in the class).

So for example a BPL-based Business Process would have this %OnDelete -

ClassMethod %OnDelete(oid As %ObjectIdentity) As %Status
{
    Set tId=$$$oidPrimary(oid)
    &sql(SELECT %Context INTO :tContext FROM Ens.BusinessProcessBPL WHERE %ID = :tId)
    If 'SQLCODE {
        &sql(DELETE from Ens_BP.Context where %ID = :tContext)
        &sql(DELETE from Ens_BP.Thread where %Process = :tId)
    }
    Quit $$$OK
}

Note this takes care of deleting the related Context and Thread data when deleting the Business Process instance. This is the desired behavior. Without this lots of "left-over" data could remain.

Note also that in fact the "AddHelper" class that assists in adding the DeleteHelper as a Super Class to various classes - does not add the DeleteHelper to Business Process classes -

// Will ignore classes that are Business Hosts (i.e. Business Service, Business Process or Business Operation)
// As they do not require this handling
If  $ClassMethod(className,"%IsA","Ens.Host")||$ClassMethod(className,"%IsA","Ens.Rule.Definition")  {
Continue
}

But if you add the DeleteHelper manually to your classes please take caution to see if the class already has an %OnDelete() method and how you'd like to handle that.

A good option is to simply add a call to the original %OnDelete in the newly generated %OnDelete() method calling ##super().

Thanks to @Suriya Narayanan Suriya Narayanan Vadivel Murugan for helping a customer diagnose this situation!

Good point!

Thanks for adding this related BP consideration Eduard.

Hi Murillo,

I replied to your similar comment on this discussion thread. In fact I referenced this discussion there as well...

So you'll find a more detailed answer there.

In any case - using both utilities could be helpful for your scenario going ahead - the DeleteHelper to hopefully avoid these kinds of cases, and this utility to validate you indeed don't have any "Purge leaks".

Hi Murillo,

Happy you found interest in this utility.

The situation you described is in fact the classic scenario I had in mind when I built this utility, so it could definitely help.

Here are a few clarifications though –

1. Ensemble Version

As I mentioned in my original post above, in “relatively” newer versions of Ensemble (since 2017.1), and definitely in InterSystems IRIS, within the SOAP Wizard there is a checkbox that if you check, the auto-generated classes will include a similar %OnDelete method to the one generated by my utility. And therefore the built-in Purge Task will take care of deleting this data (going ahead that is… see more about this in the next comment).

So in these versions, for this specific scenario (SOAP Wizard generated classes, as well the XML Schema Wizard) you don’t have to use my utility. For other cases, where you have custom Persistent classes with inter-relations, my utility would still be helpful.

2. Looking Ahead vs. Looking Back

This %OnDelete method (generated by my utility, or by checking the checkbox in the Wizard mentioned above) takes care of deleting these objects when the Message Body is deleted. But if the Message Body has already been deleted (which seems like your case), this would not help (directly) retroactively.

It would still be recommended to add it, for Purges happening going ahead (and for another consideration mentioned soon), but just by adding this, the old data accumulated will not get auto-magically deleted.

If indeed you have this old data (of objects pointed to by older, previously purged Message Bodies) accumulated then you’ll have to take care of deleting it programmatically.

I won’t get into too many details about how to do this, but here are a few general words of background –

The general structure of Ensemble Messages (in this context) is:

Message Header -> Message Body [ -> Possible other Persistent objects referenced at; and potentially other levels of more object hierarchy]

The built-in Purge Task will delete the Message Header along with the Message Bodies (assuming you checked the “Include Bodies” checkbox in the Purge Task definition, which in 99.99% cases I’ve seen should be checked). But it will not delete other Persistent objects the Message Body was referencing, at least not just “out-of-the-box” (that’s where the %OnDelete method comes into play).

So if your Message Headers and Bodies referring to the “other objects” were already deleted, in order to delete the “not referenced anymore” objects, you’d need to find the last ID of these objects (at the top most level of the object hierarchy) that still has a reference, and delete those under that ID (assuming an accumulative running integer ID for these objects).

I believe the WRC (InterSystems Support – Worldwide Response Center) have a utility built for these kinds of cases (at least scenarios), so I recommend reaching out to the WRC for their assistance, if this is your situation.

Note that if you added my %OnDelete to your classes, then finding just the top-level object in the hierarchy, the one(s) that the Message Body referenced, would be enough to delete, since the %OnDelete will take care of deleting the rest of “the tree” of objects. That’s why I said above that it won’t help the situation of this “lingering” data all by itself, but it could help.

3. Future Proofing

As you can see finding yourself in the situation of having accumulated old data that is not too straightforward to delete, is something you’d very much want to avoid. That is why I also built another utility that helps in validating, during development/testing stages, that there are no such “Purge leaks” in your interfaces.

In addition this tool also helps at providing an estimate as to how much diskspace (for database growth and journaling) your interface will require.

You can check this out here.

Hope this helps.

Thanks Evgeny, understood.

So you're saying: "InterSystems spec-first /api/mgmnt/ service generates such an endpoint." - that means that if I used the spec-first approach (which I did, I used ^%REST) I should have this /_spec endpoint? Because that didn't seem to happen...

Thanks for this tip Evgeny.

Indeed this /_spec convention pointing to the Swagger spec does seem convenient, I wasn't aware this was part of the Open API Specification (in fact I didn't find this mentioned in the Spec...).

I actually saw the method you mentioned when I was looking at the rest template provided as part of the previous contest, and thought of using it, but eventually since I used the spec-first approach, and this method you mentioned is currently (at least as-is) implemented assuming you use a code-first approach, I opted not to, and to have the same functionality (a REST API end-point providing the Swagger spec) via our already built-in API Mgmt. REST API (which I mentioned above).

I could of course consider adding something similar in the future.

Thanks Evegny.

Well no error info is a little hard to work with...

But (un)fortunately I was able to reproduce this (though earlier on in the process I tested with the test ZPM registry and it seemed to work fine...).

In any case I see (as I mentioned in my previous reply, it was worth looking there) that the UI Web Application was defined with an unauthenticated authentication method, only.

Even though the Module.xml file (link from previous version) defines it with Authentication...

Indeed when I look at the -verbose output of the ZPM install I see different behavior in each of the two CSP Apps being installed.

Even though both define this -

PasswordAuthEnabled="1"
UnauthenticatedEnabled="0"

For the REST app I see this:

Creating Web Application /pbuttons
    AutheEnabled: 32
    AuthenticationMethods:

Which is correct.

But for the 2nd app I see this:

Creating Web Application /pButtonsUI
    AuthenticationMethods:

Note no "AutheEnabled: 32" which it should have.

I edited some of the code within the ZPM class (%ZPM.PackageManager.Developer.Processor.CSPApplication) and saw that indeed the related properties (PasswordAuthEnabled & UnauthenticatedEnabled) where empty...

Playing around and comparing with some other module.xml's I found that perhaps the order of the values make a difference, so I changed:

<CSPApplication
  Url="/pButtonsUI"
  Path="/src/pButtonsAppCSP"
  Directory="{$cspdir}/pButtonsUI"
  PasswordAuthEnabled="1"
  UnauthenticatedEnabled="0"
  ServeFiles="1"
  Recurse="1"
  CookiePath="/pButtonsUI"
/>

to be:

<CSPApplication
  Url="/pButtonsUI"
  ServeFiles="1"
  Recurse="1"
  CookiePath="/pButtonsUI"
  UseCookies="2"
  PasswordAuthEnabled="1"
  UnauthenticatedEnabled="0"
  Path="/src/pButtonsAppCSP"
  Directory="{$cspdir}/pButtonsUI"
/>

And now when I run the zpm install I see thsi:

Creating Web Application /pButtonsUI
    AutheEnabled: 32
    AuthenticationMethods:

As expected.

So I pushed this update to github and hopefully this should work for you now.

In any case -

(a) I would recommend investigating why this was behavior - is this by design that the order of these attributes matter - if not - we should fix it,  and if yes - we should document it.

(b) and regarding documentation - I would recommend to document the actual attributes of this CSPApplication tag. In the current documentation there is a simple reference to the %Installer tags, but in reality though they are similar they are still different in some cases... so we should either indeed adhere to those, or document the ones that Module.xml actually uses.

For example, for relevance to the current discussion - the CSPApplication tag in our docs (referred to by the ZPM Module.xml docs) has an AuthenticationMethods attribute while the Module.xml has a combination of others instead.

Another example - Module.xml has a Path attribute and %Installer does not.

Let me know if this now works, and what you think about what I observed.

FYI

The latest version available in the Open Exchange supports now also ZPM (Package Mapper) installation.

Thanks for trying Evgeny,

Regarding the error page you are getting in the UI I believe it's pointing you to the Application Error Log in the System Mgmt. Portal (right? the screenshot above is cut...), so try and look there and let me know what you find.

One place to verify things are generally setup ok for the web side, is to see the Web Application was created and defined correctly (including authentication, pointing to the correct physical folder, etc.).

Let me know what you find.

Regarding the Swagger/Open API spec - you find it in any of these -

1. A json file under the /swagger folder (as mentioned towards the end of the Readme). I used this for easier editing of the spec within VSCode with the relevant plugin.

2. The .spec class /src/zpButtons/REST/spec.cls

3. Using our built-in API Mgmt. REST API, in this case the URL would be, for example:

http://localhost:52773/api/mgmnt/v2/%25SYS/zpButtons.API.REST

With either of these you can take the JSON and view it via the Swagger Editor - https://editor.swagger.io/

Let me know if this is what you meant.