I noticed ccikara posted about trying to get this ECMAScript example to
work a few days ago


I found it straightforward to get it working, but came across a strange

In my specific solution, I was trying to avoid actually storing the
imported octect stream in the IDV. This is because only one connected
system actually needed this data - my original plan was to import from
the URL within the driver for the connected system (triggered on demand
by changes in other attrributes in the IDVault) and send to the
connected system.

However the connected system (Active Directory) wouldn't accept the
base64 encoded data output by this ECMAScript example. The remote loader
trace showed it simply got skipped by the driver shim.

What did work, was to instead import each file using this ECMAScript
example via a null driver that just wrote the imported data into the
photo attribute in the IDV.

Then it was a simple matter of configuring subscriber-sync on the
specific attribute in the filter of the connected system driver.

This time, I could verify that the photo was synchronised correctly.

I realise that this is probably better practice, rather than embedding
it all in the one connected system driver. However I was curious why my
original approach didn't work.

Upon closer inspection in the trace, the base64 encoded value differed
between the ECMAScript function and the photo attribute synchronised to
the connected system.

when synchronising octet-streams (like the photo attribute) to a
connected system I couldn't see any other characters than A-Z
(upper/lowercase) and 0-9 my understanding is that this would make it
base62 rather than base64. Does IDM use base62 in such a situation? If
so why have I only seen reference to base64 when discussing octet/binary