SDO: Setting 'merit' on a CRP Policy

[y***@gmail.com]

The documentation regarding for setting of the merit (aka Processing
Order) on a CRP is a bit confusing. Say I want to make sure my new
CRP is at position #3. How do I do that? The docs and the sample CRP
creation VB.NET code mention that setting the merit to any value at
creation time is ignored. And that you must apply changes (that
create the policy) to the policy, then edit the policy to change the
order.

Here's a code snipit (C#) I used to create the policy object...
// create profile first
....

// now we can create the matching policy...
ISdoCollection CRPolicies = (ISdoCollection)
sdoServiceSDO.GetProperty((int)
IASPROPERTIES.PROPERTY_IAS_PROXYPOLICIES_COLLECTION);
ISdo newPolicy = null;

// add a new policy to the collection and set its name...
object tempObject = newPolicy;
CRPolicies.Add(MyConstants.CRP_NAME, ref tempObject);
newPolicy = (ISdo)tempObject;

// edit conditions/constraints...here
....

// Set the policy's merit
//
// According to this docs, this value is ignored when you
create a new policy. So, we'll just set it to 1 for now
tempObject = 1;

newPolicy.PutProperty((int)POLICYPROPERTIES.PROPERTY_POLICY_MERIT, ref
tempObject);

// match up this policy with the corresponding profile...
tempObject = MyConstants.CRP_NAME;

newPolicy.PutProperty((int)POLICYPROPERTIES.PROPERTY_POLICY_PROFILE_NAME,
ref tempObject);

// save the policy
newPolicy.Apply();

// now that we have saved those settings, we can update
the merit value...
//
// fetch our newly create policy so we can edit its merit
value...

tempObject = MyConstants.CRP_NAME;
newPolicy = (ISdo) CRPolicies.Item(ref tempObject);
tempObject = _CRPPosition;

newPolicy.PutProperty((int)POLICYPROPERTIES.PROPERTY_POLICY_MERIT, ref
tempObject);
newPolicy.Apply();

[Tony]

The documentation regarding the setting of the merit (aka Processing
Order) on a CRP is a bit confusing.

FWIW, here's the comment from the help...

From http://msdn.microsoft.com/en-us/library/bb960696(VS.85).aspx

"You cannot set the merit value of a policy when you first create the
object. A new policy object is always applied in the same merit
location. To order your policies, create the policy object and set its
values. Apply all the changes to the object, and then set the
appropriate merit value and apply the changes."

I have found that you *MUST* specify a value for merit at creation
time otherwise you get an exception when you 'Apply' other changes
(name, profile name, conditions, etc.) to the same policy object. If
you do set the value at creation time expecting it to correctly set
the processing order, the behavior is odd. Sometimes doing correctly
sets the processing order, other times it does not.

[Tony]

Post by Tony
"You cannot set the merit value of a policy when you first create the
object. A new policy object is always applied in the same merit
location. To order your policies, create the policy object and set its
values. Apply all the changes to the object, and then set the
appropriate merit value and apply the changes."

OK, after a bit more debugging and tracing, it seems as though the
value I set upon creation can be used (I don't have to re-assign the
value after I create the policy). However, it seems as though the API
expects me to adjust the merit values for all other polices in the
database.

So, when I create/add a new policy and assign its merit to say 17, the
SDO API will gladly accept that value even though there are only 5
existing policies (I'm adding a 6th). Later I update my policy's
merit to 3, but doing so will result in two policies with the same
merit (both having a merit of 3). The API doesn't seem to care if
this happens. However, if you view the CRPs in the IAS snapin they
seem to get re-ordered and fixed (1-6). This behavior seems to
indicate that _I_ must re-merit all existing policies when I want to
insert my policy at a particular location in the processing order. I
should also re-merit when I remove a policy as well (unless it is the
last one). Sound about right?

FWIW, I created this helper routing to dump the contents of the policy
collection at various times...

private void DumpPolicyCollection(string tag, ISdoCollection
policies)
{
StringBuilder sb = new StringBuilder(224);
sb.AppendLine(tag);
sb.AppendLine("Count: " + policies.Count.ToString());

foreach (ISdo aPolicy in policies)
{
object name =
aPolicy.GetProperty((int)POLICYPROPERTIES.PROPERTY_POLICY_PROFILE_NAME);
object merit =
aPolicy.GetProperty((int)POLICYPROPERTIES.PROPERTY_POLICY_MERIT);
sb.AppendLine(merit.ToString() + ":Name--> " +
name.ToString() + ".");
}
EventLog.WriteEntry(MyConstants.APP_NAME, sb.ToString());
return;
}

[James McIllece [MS]]

snip<

Thanks very much for posting this information; the writer of the topic in
question has been notified and will be updating the topic.

[Tony]

On May 13, 4:30 pm, "James McIllece [MS]"

Post by James McIllece [MS]
Thanks very much for posting this information; the writer of the topic in
question has been notified and will be updating the topic.

My final solution was...

Goal: Create a canned CRP at a particular place in the processing
order

Solution:

1) If the CRP Profile I need exists, delete it.
2) If the CRP Policy I need exists, delete it and shift all "higher"
merit values down by one.
3) Create new CRP Profile and apply (save) changes
4) If needed, shift the merit value of all CRP policies that will be
"higher" than my new policy up by one.
5) Create new CRP Policy including **correct** merit value
6) Apply (save) changes to CRP Policy
7) Reset (so IAS re-reads the config changes)

I suspect 99% of the time this will the only CRP, so the shifting will
never occur. I added support for specifying a particular position in
case our customers use the same IAS for some other purpose than our
application (not likely).