Packaging the eDirectory Schema

[jimgoodall]

Hi folks,

Over the years I've worked on lots of projects where a Development / User Acceptance Testing / Production environment model is utilised.

Packages make moving drivers / resources through that model really easy. One thing keeps coming back to bite me every now and then though is remembering to move the supporting schema updates into the higher environments.

My thought "Wouldn't it be awesome to include your vault schema in an Identity Vault package"

Just wanted to canvas thoughts really on whether you agree, and if not, I'd be interested to hear how you version control and manage your schema between environments?

Cheers!

Jim

[lhaeger]

jimgoodall wrote:

> My thought "Wouldn't it be awesome to include your vault schema in an
> Identity Vault package"
>
> Just wanted to canvas thoughts really on whether you agree, and if not,
> I'd be interested to hear how you version control and manage your schema
> between environments?

You can package schema as a generic resource objects at ID Vault level and
package them. Copy/paste the classes and/or attributes required for your driver
as SCH or LDIF and you'll always have the correct schema right where you need
it. Of course this does not deploy the schema automatically, but it's easy
enough to save it to a file, then import into the ID Vault with Designer and
deploy it.

So basically you have schema under version control and distribite it with the
drivers that require it. Only the actual process of extending the schema
remains a manual process. Would be nice to have that automated as well, you
could probably create a service driver that reads all your schema resources and
uses ldapmodify to deploy their contents. Would I want this in my production
environments? Not sure... 😉

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

[jimgoodall]

Thanks - I hadn't considered using a resource object. More elegant than forgetting to deploy the schema 😉

Not sure how you'd make that work with an IDV level package though as a DirXML-Resource objects can only be contained in a Driver, Driver Set, Library, Publisher or Subscriber. Unless of course I am misunderstanding you.

Would work if the resource object was added as a driver set object and packaged there though. Not perfect, but good enough.

I'd agree, whilst we could write a service driver to unpack the resource object, IMHO it'd be overkill, and as you say, could be the source of sleepless nights! :eek:

[lhaeger]

jimgoodall wrote:

> Not sure how you'd make that work with an IDV level package though as a
> DirXML-Resource objects can only be contained in a Driver, Driver Set,
> Library, Publisher or Subscriber. Unless of course I am
> misunderstanding you.

Create new library at tree level, e.g. "Schema Extensions"m then create
resource of content type "text/+text" inside. Create tree level package, add
the resource to it and make tha package a dependency to the driver/driverset
packages that rely on this schema extension. I'd probably create one package
per aux class.

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

[jimgoodall]

Thank you sir!

Again, I had not considered adding a library outside of the driver set 🙂

[geoffc]

On 7/5/2018 10:52 AM, Lothar Haeger wrote:
> jimgoodall wrote:
>
>> Not sure how you'd make that work with an IDV level package though as a
>> DirXML-Resource objects can only be contained in a Driver, Driver Set,
>> Library, Publisher or Subscriber. Unless of course I am
>> misunderstanding you.
>
> Create new library at tree level, e.g. "Schema Extensions"m then create
> resource of content type "text/+text" inside. Create tree level package, add
> the resource to it and make tha package a dependency to the driver/driverset
> packages that rely on this schema extension. I'd probably create one package
> per aux class.

In Lothars case, I agree with the one package per aux class, but I think
I still might include a single consolidated case.

I.e. If my package had a Grooup and User support set of packages, then I
certainly would split up the schema extensions. But if it is one set of
schema changes, I would just do one resource for simplicity.

[geoffc]

On 7/5/2018 10:24 AM, jimgoodall wrote:
>
> Thanks - I hadn't considered using a resource object. More elegant than
> forgetting to deploy the schema 😉
>
> Not sure how you'd make that work with an IDV level package though as a
> DirXML-Resource objects can only be contained in a Driver, Driver Set,
> Library, Publisher or Subscriber. Unless of course I am
> misunderstanding you.
>
> Would work if the resource object was added as a driver set object and
> packaged there though. Not perfect, but good enough.
>
> I'd agree, whilst we could write a service driver to unpack the resource
> object, IMHO it'd be overkill, and as you say, could be the source of
> sleepless nights! :eek:

Consider doing indexes you want added as well as an LDIF?

I would do it as Driver Set level, even though logically it should be
IDV level. But really who has more than one Driver Set these days anyway.

[lhaeger]

Geoffrey Carman wrote:

> But really who has more than one Driver Set these days anyway.

But really, what would make a driverset package better (in any way) than a tree
package?

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)

[geoffc]

On 7/5/2018 2:21 PM, Lothar Haeger wrote:
> Geoffrey Carman wrote:
>
>> But really who has more than one Driver Set these days anyway.
>
> But really, what would make a driverset package better (in any way) than a tree
> package?

Nothing. But if it is awkward or out of 'sight' outside the driverset
to use an IDV package, a driver set package should be fine as well.

Both ways work perfctly well.

[TE]

geoffc;2483537 wrote:
On 7/5/2018 10:24 AM, jimgoodall wrote:
>
> But really who has more than one Driver Set these days anyway.

You would be surprised...

[geoffc]

On 7/16/2018 3:04 PM, tse7147 wrote:
>
> geoffc;2483537 Wrote:
>> On 7/5/2018 10:24 AM, jimgoodall wrote:
>>>
>>> But really who has more than one Driver Set these days anyway.
>
> You would be surprised...

Fair enough. But most cases are probably fewer than 3. 🙂

[geoffc]

On 7/5/2018 9:19 AM, Lothar Haeger wrote:
> jimgoodall wrote:
>
>> My thought "Wouldn't it be awesome to include your vault schema in an
>> Identity Vault package"
>>
>> Just wanted to canvas thoughts really on whether you agree, and if not,
>> I'd be interested to hear how you version control and manage your schema
>> between environments?
>
> You can package schema as a generic resource objects at ID Vault level and
> package them. Copy/paste the classes and/or attributes required for your driver
> as SCH or LDIF and you'll always have the correct schema right where you need
> it. Of course this does not deploy the schema automatically, but it's easy
> enough to save it to a file, then import into the ID Vault with Designer and
> deploy it.
>
> So basically you have schema under version control and distribite it with the
> drivers that require it. Only the actual process of extending the schema
> remains a manual process. Would be nice to have that automated as well, you
> could probably create a service driver that reads all your schema resources and
> uses ldapmodify to deploy their contents. Would I want this in my production
> environments? Not sure... 😉

Oh that would be cool!

I do the same as Lothar suggests.

When doing a SOAP shim as well, I include the full WSDL I based my work
on, since WSDL's change over timie, and then you have the reference
against which it was developed.