Per a different thread, I have a source="connection" which is illegal in
my SAP UM EntitlementConfiguration object.

I need a parameter set to a hard coded string. I.e. in the entitlement
parameter list, I need ID=geoffc|LSNAME=DV3CLNT400|CTYPE=non-cua at a
minimum. The ID is easy. The next two are basically hard coded string
per driver.

The connection approach I am sure was intended, somehow to allow for the
fanout configuration where you might need many entitlements, one per
system in the landscape that you fanout too.

Since that is illegal I need to fix it to use a hard coded string per UM
driver. (Non-fanout mode).

Steve says the legal values for source is:

In a <parameter> node, how do I specify a literal string to be set then?

Looking at some examples I see these:

<parameter mandatory="true" name="AG" source="read-attr"
<parameter mandatory="true" name="LSNAME" source="connection"/>
<parameter name="FROM" source="external" source-name="fromDate"/>
<parameter name="TO" source="external" source-name="toDate"/>

I see the first is source='read-attr', and then @source-name specifies
the attribute from the query. Ok. That makes sense.

Then my bad example of LSNAME with connection.

Then FROM and TO whose source is external, and source-name is toDate.
Hmm... What does that mean?

Looking at an AD drivers config, I see:

<parameter mandatory="true" name="ID" source="association"/>
<parameter mandatory="true" name="ID2" source="src-dn"/>

Those are easier. assoc and src-dn are well known default values. Ok.

Another is helpful:
<parameter mandatory="true" name="ID" source="read-attr"

Since ADDomainValue I know is not a real attribute, I also know that the
Google Apps driver, and AD driver have these odd policies that return
hard coded data, on specific, odd queries. That is, if you inject a
query for ADDomainValue, there is an OTP and ITP policy pair that
reformats the query into a hard coded response.

I always thought that was bizarre, but maybe that is the answer i need?
To copy how the Google Apps driver does it, query for some non-real
attribute, let the policies make it skip the shim and return the hard
coded value I want. Kind of circular, but does make the otherwise odd
behavior make some sense.

Specifically, go add an AD driver, from Packages with everything, and
look at the policy: NOVLADENTEX-itp-EntitlementsImpl

This ends up generating a response to a query for ADDomainValue, with:

<nds dtdversion="4.0" ndsversion="8.x">
<product version="?.?.?.?">DirXML</product>
<contact>Novell, Inc.</contact>
<instance class-name="ADDomain" src-dn="a">
<attr attr-name="ADDomainDisplayName">
<value>Account for domain: a</value>
<attr attr-name="ADDomainDescription">
<value>User account in Active Directory domain a</value>
<attr attr-name="ADDomainValue">

Hmm... This seems somewhat of a workaround...

Looking at the values Steve offered,

The easy ones we see are src-dn, association (which use the source DN
and Assoc value to fill the parameter values).

read-attr is do a query, for the source-name provided value.

I guess search-attr, with source-name would return all values that match
the search-attr? (Can you compound this somehow? Or just one allowed).

But what is external? The examples I have of external, suggest a
source-name of fromDate and toDate. Which makes me wonder if those are
Workflow field values?

Hmm, maybe I could more simply define name='LSNAME' source='external'
source-name='lsname' and in my Add Role call, add a string 'lsname' with
the value I want? That seems a lot simpler. Maybe a CTYPE one as well.

I know this is sort of rambling, but hoping someone knows enough to
help, and maybe this helps someone else understand stuff as well.