What's New in Designer 4.5.2

0 Likes
over 6 years ago
Recently NetIQ released Designer 4.5.2 and I thought I would do another of my What's New series articles about the listed changes and enhancements. You can see some of my other articles in that series, specifically about Designer here:






As you can see, post the release of IDM 4.5, Designer has gone through a number of patches and revisions. Some of those changes are simple bug fixes, and some are major enhancements. One issue that keeps coming up is that to add new drivers, requires an update of sorts to Designer. This is because the palette and the list of drivers to be added is not specifically controlled by the set of Packages (Base Packages specifically) but also by code in Designer.

Thus with the release of each new driver, at least a minor update to Designer is required. This update includes two new drivers as we will see below. This is a bit of a chicken and egg problem, in that the new drivers cannot be released until there is a Designer patch providing support. Thus one always comes first, rarely at exactly the same time as the other. Thus while the Designer patch to add MDAD support has arrived, the driver itself and the needed packages has not. But this is just a minor timing issue and no doubt it will be released soon enough.

Enhancements for Designer



Java 8 Support:
Designer has been updated to support Java Development Kit 8 (jdk8u60) or Java Runtime Environment 8 (jre8u60).

Support for Eclipse 4.4.1
Designer has been updated to run on Eclipse 4.4.1.

Together these two changes are good news. Java 7 (1.7.x) is being deprecated soon and will lose support from Oracle and so we need to get over to Java 8 (1.8) on all products sooner rather than later. Additionally this is a change of the underlying Eclipse project itself, which is very good news. With the move to Designer 4.5, they moved from a fairly old Eclipse build to a much newer (Eclipse 4.3.1), but not bleeding edge version. Now they are moving to the 4.4.x build of Eclipse. This made a big difference on memory leaks and performance when they moved to 4.3.1 and hopefully the move to 4.4.1 will help as well.

Support for Drivers
Designer now supports the creation and configuration of the following drivers:

Multi-Domain Active Directory Driver
Multi Domain Active Directory Driver, which supports provisioning of multiple domains in an Active Directory forest. This driver also supports Global, Local and Universal groups within the same forest. The driver simplifies the overall deployment and integration of the entire Active Directory forest with your Identity Manager solution.

If you already have the NetIQ Active Directory driver, you can continue using it for most of the Identity Manager deployment scenarios. You would use the Multi-Domain Active Directory driver to enable your enterprise with multiple domain support.

The Multi-Domain Active Directory (MDAD) driver is a new addition and was shown at the last BrainShare where it was called AD^2 (Active Directory Advanced Driver). I think I preferred the old name, but I stink at naming so ignore me. The IDM User Group that I run (email me if you are interested) had a demo of this driver shown by the developers a couple of months ago. I take detailed notes and record all the sessions on topics of interest to IDM professionals.

The basic idea is that the existing ADDriver.dll continues to be used. But a .NET wrapper is now used that talks to what is really a JMS Message Queue. The driver shim is really a JMS shim now, sending and receiving messages from the message bus with events. The event might need to processed by the server running the Remote Loader or a different server running an agent.

Additionally this supports a single forest with multiple domains using one driver. Before, a driver per domain would have been required even if they were all part of the same forest. Now a single driver can handle as many domains in a forest as needed. The addition of agents allows for better distribution of the processing load, and makes the calls with ADDriver.dll code as needed. This also allows for some fault tolerance where two agents can be configured to fail over if one goes down.

During the beta there was an interesting twist, in that you had to add the driver from the palette. Drag and drop it onto the Identity Vault, since that triggered an extra bit of code in Designer to ask you to specify the connection objects which just adding it via right click on the Driverset and Add new driver did not. We will have to see if this was fixed in the final release.

REST Driver
REST (Representational State Transfer) is an HTTP-based protocol used for Internet communication. The Identity Manager driver for REST enables identity provisioning and data synchronization between an Identity Vault and any RESTful service.

For more information about creating and configuring this driver, see the NetIQ REST Driver Implementation Guide at http://tinyurl.com/ot8sct7.

Now technically this was added a bit earlier in the 4.5.1 release I think, but regardless, it is listed in the Readme for 4.5.2 so lets roll with it.

The REST driver is a great addition to the stable of IDM tools provided by NetIQ. Like the SOAP driver this is more of an API or transport driver, than a standard application driver. The REST driver does not specifically support any application, rather it supports many different web services that use the REST standard to communicate.

The REST driver is probably worthy of a series of articles on its own, but for now suffice to say it supports more authentication methods (Basic, Anonymous, and OAuth) and has a Java class you can call in the Input or Output transform that will convert XDS to JSON and JSON to XDS. I worked on something like this myself and used it as a Java Byte Modifier Array extension to the SOAP driver. My issue, which this driver fixes is that a REST call might be all URL, and no payload, which the standard SOAP shim does not like. This shim is perfectly comfortable with that which makes it much easier.

Fixes Found in this Patch



Bug 939458: Ability to Deploy a Linked Schema Mapping Policy for a Driverset. This service pack resolves an issue where you cannot view or deploy a schema mapping policy that you created and linked to a driver.

This bug was found in a case where a site had hundreds of drivers of the same type, same design and needed to deploy them all. But to support 100 instances of any driver is painful. So they did something I have done before and built the driver in two pieces. First all the policies exist in a library object. This is delivered by a Driver Set level package, just to create the needed objects, with no linkage to any particular driver. Then 100 copies of the needed driver are built using the second package that delivers basic config and only linkage info. That is, the driver object itself in eDirectory has almost no objects underneath it, but the DirXML-Policies attribute has all the policies linked in from the Library that holds the objects.

The other alternative would have been to use the same packages delivering the same code, 100 times, which is too hard to manage and update. Also it really does add way more objects than needed to the tree when they are functionally identical otherwise.

To do an upgrade now, a single Driver Set package is updated to deliver the new code in policies and when ready each of the 100 drivers can be restarted to use it.

What the developer of this approach found was that the linkage worked for Policies and other objects, but failed inexplicably for Schema Map objects. Probably one of those silly oversights, where no one thought to test that aspect of it.

I know that including a Schema Map object from a Library works (have a client where it ran for years that way) but the issue was that the Package's Linkage setting did not work. This is similar to a bug fixed in 4.5.1.1 where the Subscriber Event Transform was not a listed value for Linkage locations I would think.

Bug 926807: Designer Can Open a Project that has been Renamed This service pack resolves an issue where Designer might fail to open a project that you have renamed. For example, you changed the project name from TestProj1.proj to Test Project 1.proj, then Designer did not open the project.

If you have ever decided you should backup a project in Designer, you have two options. First make a copy, to a different name, and second export to a ZIP file. If you export it, and wish to import it again but do not wish to delete the original project, you need to rename it, since you cannot have the same name twice in one workspace. It has to do with the fact that the projects are stored as directories with that name and file systems will not allow duplicate names in the same folder.

This bug notes that if the project was named "My Project" or you renamed it to "My Project" the key being a space in there, then the rename did not properly complete.

If you copy or rename a Project you will see it chug through tons of files and directories and basically change a lot of entries, since there are references between objects inside the objects (Almost all are text files, go spelunking it is interesting reading, I recommend it highly) based on file path which need to be updated. There seems to have been a problem in at least one code path in dealing with names with spaces. I personally never ran into that since I do not trust anything to work properly with spaces, and use dashes or underscores instead.

Bug 891741: Designer Provides Status of SVN Cleanup Tasks Issue: When you run an SVN cleanup during a runtime job, Designer does not provide a message when the clean up tasks are completed or whether the clean up failed. Instead, you must check the Error Log.

Fix: Designer provides a notification bar to indicate the status of the SVN cleanup job The notification disappears when the job completes without errors.

The SVN integration in Designer is something that could use some attention. This bug notes that when you call the SVN Cleanup option you did not get told when it completed, and it could take some time to process. Stopping a session mid-cleanup is highly likely to cause problems so it is important to know when it is done. Additionally, Designer is often run on a Terminal/Citrix session on Windows, or X on Linux, and depending on the config dropping the session can kill the running apps. Thus before ending a session it is important to know when this is done.

I love the idea of SVN support for Designer, I just hope they get a chance to work on improving it more in future versions.

Bug 902005: Allows You to Open a Designer 4.0.2 Project with Affecting the Layout

Issue: When you open a Designer 4.0.2 project in Designer 4.5.x, Designer provides an option to migrate the linkages. If you select Yes, then Designer rearranges the driver layout in the Modeler view. This issue occurs because Designer 4.5.x reads the project object first, which prevents it from gathering information about the layout in the Modeler view.

Fix: When you opt to migrate linkages, Designer now opens the Modeler first, then gets the project object from the active editor.

This bug was very annoying and I am glad to see it fixed. With the release of IDM 4.0.2 patch 3 a fix for the ordering of policies was implemented that was long needed. Basically it started storing the package linkage information in eDirectory as the attribute DirXML-pkgLinkages (an XML blob that tells Designer where this policy belongs.) This apparently was the fix for importing a driver an Designer would refuse to match the eDirectory ordering no matter what you tried. Usually in a case of a mix of packaged and non-packaged content. With this fix, Designer is supposed to more reliably import it. I never understood this, since the ordering is not stored as the order of attributes in a multi valued attribute, rather it is stored in DirXML-Policies, which has the syntax of Typed Name. Typed Name syntax has three components, a DN (the object to be linked, policy, XSLT, Resource, GCV, etc), then two 32 bit integers. These are used as counters. One (Order differs in NCP vs LDAP view) tells you which policy set to use, where GCV's, ECMA, and each policy set gets a integer from 0-16. (Obviously good to 32 bit signed integer in size) and the second tells you the ordering within that assignment. Check out this article for more info: Talking about the DirXML-Policies attributes

The numbering of the policy sets, GCV, and ECMA are as follows:
     0 Schema Map
     1 Input Transform
     2 Output Transform
     3 ECMA Script Object
     4 Sub Event Transform
     5 Pub Event Transform
     6 Sub Match
     7 Pub Match
     8 Sub Create
     9 Pub Create
     10 Sub Command Transform
     11 Pub Command Transform
     12 Sub Placement
     13 Pub Placement
     14 GCV Objects
     15 Startup (New in IDM 4.0.2.3)
     16 Shutdown (New in IDM 4.0.2.3)

But the second integer, telling you that Policy X is position 0, and Policy Y is position 1, seems eminently clear, so I do not understand why there was ever confusion. This is regardless of Packaged or not, that is how the end result of what is currently stored in eDirectory is represented.

Nevertheless there was some need to fix it, and Package Linkages were the method. Each project that was created before Designer 4.0.2 AU4 I think needs to be converted. Conveniently, Designer would ask if you would like to convert it as you opened each project up that needed it. However if you said yes, then the entire layout you may have spent much time getting just right is reset to a default square layout. I know I personally like to have my AD drivers near each other, my text drivers together, and so on. The default layout on a large project is terrible.

They fixed it, which makes me happy. But better this bug explains why it was happening due to the ordering of how they loaded the project.

Bug 891720: Designer Helps Resolve a Conflict in Driver Status between Designer and the Identity Manager Engine

Issue: When you attempt to deploy or reconcile a driver that is disabled in Designer but enabled (auto or manual) and running on the Identity Manager engine server, Designer fails to notify you of the issue or to provide you a method for resolving the conflict.

Fix: When this type of conflict occurs, Designer now displays a message that provides the following options: Stop the running driver where Designer stops the driver and marks it as disabled Keep the driver running where Designer does not deploy the disabled setting for the driver Resolves an Issue with Erroneous PRDs in the User Application Driver

This is related to an issue that you cannot set a Running driver to state of Disabled, it has to be stopped first. You get a -641 error which is the general IDM action is not allowed at this time or this way. Now Designer at least tells you what is going on.

Bug 921253: This service pack resolves an issue where the User Application driver contains erroneous provisioning request definitions (PRDs). This issue occurred when you created a custom package for the driver then uninstalled that custom package. During uninstallation, Designer failed to remove the PRD objects associated with the custom package.

I am not sure I really understand what this bug is about, but Packages and PRD's have a series of issues, so I am glad to see them knocking some of them off the list.

Labels:

How To-Best Practice
New Release-Feature
Comment List
Anonymous
Related Discussions
Recommended