New post
AllAccepted answers
Steve Pisani · Aug 17, 2017

John is absolutely right.

You cannot set this value.  In fact, I should have said in my earlier post that the advertised (documented) maximum number of connections per License Unit is and always has been only 12.

The fact it is 25, is somewhat common knowledge and is a sort of grace limit, however I always tell my customers that you should work on the assumption that InterSystems could eventually enforce the advertised number of 12. If this happens it should not come as a shock to anyone.

12 connections from a user interacting with Cache, coming in from the same address, should be ample.

Steve

Steve Pisani · Aug 17, 2017

Hi,

The code below returns the maximum number of connections a user can make while consuming one license unit.

Write ##class(%SYSTEM.License).MaxConnections()

It is a global setting, and, it is not related to the License Unit Authorized value.  That value is how many license units (not connections per unit), you can take out.

sincerely,

Steve

Steve Pisani · Jul 12, 2017

Hi Carey,

As you probably realised, the intention of the business rule (and rule sets within a rules class) is to typically have 1 sets of rules that are applied to a message, but for which you could have multiple versions, based on an effective date/time period.  That is:  if the date is X run rules set# 1, but if the date is Y run rule set#  2.  

If date ranges overlap, than, whichever is the first valid date range in the order in which the rules sets are arranged, defines which set of rules is executed. This is important to remember for later...

You can create 'Rule Set #2' ahead of time, making sure that the effectiveBegin of rule set #2, is immediately after the effectiveEnd of rule set #1 (as you indicated you wanted).

However, the second rule set would need be essentially, a copy of the first set - except for the changes to an individual rule item(s) that you want a different behavior for.  

Admittedly, cloning a whole rule set to another copy is labor intensive via the UI, but, extremely easy if you open the generated class in Studio - as you can just copy/paste the XML elements between the <ruleSet> tags,  save and re-compile. After you have your second set,  make your edits to rule set 2's effective date range, and whatever rule changes needed.

The Delegate action sends the message to another rule definition altogether, and, the Send sends the message to any other business component, (which can be a routing rule).   Using these two actions, based on any condition regardless, would require you to build a new rule definition or component to act as their target which you said you did not want to do, so, they are out.

Now - What you *can* do is write a user defined function to retrieve a rule definition's second rule set date range, and, use the value from this function in a conditional statement that drives the behavior of any of your first rule set's rule items.  You must ensure that Rule Set #1, however, is always the one that ever gets executed and the system does not ever fall on to running rule set #2 - so - even though you put in  a date range for rule set #2, leave date ranges for rule set #1 blank or wide open, so it will be the first and only one that will qualify for execution every time. 

Warning: This is not standard use or best practice, and I'm not recommending you do this - as it will effectively negate the rules sets with effective periods feature. which in the future, you may want to use.   I would stick with the approach of cloning Rule Set 1 into Rule Set 2, setting an appropriate EffectiveStart/end ahead of time, and making the individual changes you need to take effect in the future. 

Steve

Steve Pisani · Jun 9, 2017

Hi,

There are a number of reasons for it.  

One that comes to mind, for example, is if your user accounts expire, (also perhaps, if you just forgot passwords, or there is some other user authentication issue) -  you will not be able to get into Cache to extend the expiry date, effectively - you will be locked out.

Starting Cache in Emergency Access Mode will allow you to specify a one-time, single-use account you can use to log into Cache, then into security settings, and, re-enable those account that should no longer be disabled.

You can then restart Cache with emergency access and you will be able to access Cache again using your newly re-enabled user accounts.

Steve

Steve Pisani · May 31, 2017

Hi,

Upcoming 'Show Inherited' feature will definitely be welcome - thanks, and, using ctrl+space to invoke intellisense to get a list of options for class elements such as: indices, properties, methods, XData elements, Foreign Keys, Projections and Queries  does cover a lot of what is apparently missing..

I have not - however, been able to use the ctrl+<space> to list out options for Parameter of a class.

I have not managed to get Atelier to show me the parameters of a property type, (like MAXLEN, etc)

Property Title As %String (MAXLEN = 50, POPSPEC = "Title()")

This is available in Studio's Inspector window, and is very handy to have: both as users are starting out and can't remember exactly the name of a given property's parameters (VALUELIST, DISPLAYLIST, MAXLEN, etc...), but even and more so I guess, when using custom property types. 

I couldn't find a way of bringing these up.

thanks - 

Steve

Steve Pisani · Mar 23, 2017

Hi Ryan,

The message that you pass to your SOAP-based business operation should (as you indicated in your 3rd bullet point), contain both the extracted HL7 data, and the authorization key you retrieved from the previous step.

I'm assuming your SOAP Business operation you are using in the last step has been automatically generated by the Studio wizards, so, you will have a Class Method for each web method of your SOAP service.

You need to edit the default generated versions of these methods the wizard gives you, in order to add your SOAP Header.

You can access   ..Adapter.%Client in this business operation to get access to the private instance of the web service client class, so, using

   Do ..Adapter.%Client.HeadersOut.SetAt(...)

You can set the headers for that particular message invocation.

Sincerely - Steve