Monday, August 04, 2008

ILM Drop Files and the XMA 'ChangedAttributes' Array

Drop files were one of my favourite features in MMS 3.0 when I first saw it, largely because everything in MMS 2.2 was based on files (except for the ADMA). Why are drop files cool? They are cool because they are the same format across all managment agents in ILM, and contain the same kinds of data, so you can easily use them for reporting. It gets better, you can also create a drop file on one machine, then play it into an MA on another machine. Great for trying to repro a rules problem.

A couple years ago I stumbled upon an issue where drop files worked but caused an issue in my XMA. The result was that I had to decide on drop files, or the feature in the XMA I was trying to use.

First a quick look a the XMA's ExportEntry() method:
public void ExportEntry(
ModificationType modificationType,
string[] changedAttributes,
CSEntry csentry
// TODO: Remove this throw statement if you implement this method
throw new EntryPointNotImplementedException();

The code snippet above is the code generated by the ILM UI, except I have placed in a line to raise the debugger for me. Pretty plain so far, so I'm not introducing any bugs of my own.

Now the problem. Notice the changedAttributes array. When drop files are NOT turned on, this array behaves normally. You can expect to see in there a list of attributes that are changed. One might use this to send changed attributes to the target system.

Turning on drop files in an XMA causes this array to be empty. I can repro this by watching the array in the debugger using an Export run profile to turn drop files on and off.

Drop files turned on causes the array to have no items (looks like a bug).
Drop files turned off causes the array to have items (expected behaviour).

Moral of the story is, drop files good, bug in XMA not so good, proceed with caution and use the features accordingly. If you really need this one solved, raise it to PSS and let them know somebody needs this fixed.

No comments: