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

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

..and I must add... 'No' - it is not used to establish a connection without authentication. For that, the connection method would need to be specifically defined to allow unauthenticated access, and that needs to be done from within Cache.

Steve

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