0
Answered

Allow for attached images to be managed

Adam van Vliet 13 years ago in UNIFYBroker/Frontier ichris/chris21 updated by anonymous 8 years ago 10

From discussions on TATTS-7, allow for images to be saved and retrieved.

Please see attached demo code.

Either create a test application for POC, or add it straight to the product if you feel it will be quicker.

Thanks.


Photos.cs
RE Chris21 Staff PhotosAttachments via GTR interface.msg

Earlier this morning, it was verified that images are being correctly retrieved from chris21 via the connector. Identity Broker v3.0.6 required an additional patch to the binary value type in order to get binary values to correctly flow out of Identity Broker into IdM engines eg. FIM. Following this, I have been investigating the write back functionality - the provided example above only contains an example of reading a file. Communication with Frontier will be needed to determine the appropriate command for sending data using the "repositorytransfer" business rule is not provided, and has not yet been discovered (eg. changing the "fetch" keyword of the retrieval command to "update", "save", "store", and "make" fails with an unknown process error).

Moreover, polling via the current EAI set up will detect and successfully pull an image for a user if the user did not have an image before, but it does not detect if a user has changed their photo to another file. A full import will still retrieve the image successfully. Currently carrying out a little further investigation to see if EAI can be configured to detect this level of change so we can also mention this to Frontier if necessary.

Release management for Identity Broker v3.0.6 Patch 3 will also need to be carried out for implementations that wish to use this feature of the connector.

Email sent to Adam and forwarded to Frontier regarding adding/updating images, and above note on EAI.

Afternoon Adam,

I have successfully been able to retrieve the default attachment from chris21 forms using the example code provided to us by Frontier. Using the GTR interface, I have been able to retrieve the default image as a hex string, and convert it into its binary representation. However, I am having some difficulty working out how best to go about adding/updating images back to chris21.

Retrieving staff photos is carried out by checking the default attachment for a particular user on the employee details form, and then performing a “fetch” process command using the “repositorytransfer” business rule. According to information from Frontier, adding an image is done by doing the reverse – breaking the image into blocks of 3072 bytes, and sending it via GTR. However, I have been unable to work out which GTR value to use for the “process” command as the supplied example does not contain a mechanism for writing back to chris21, and I have not been able to find any information on the “repositorytransfer” rule in the product documentation or chris21 help files.

Any assistance regarding documentation of this business rule or process, instructions on how to access the commands available for particular business rules in the GTR interface (such as a help command), or an example of writing images back to chris21 via GTR would be a big help in adding this feature to Identity Broker for chris21.

As another note, as you know, we use the EAI interface for polling chris21 systems. If an employee with a non-existing photo has one added, EAI allows our software to detect that a change has occurred. However, the interface does not cater for alterations to an existing photo. I believe this is because the EAI check is only registering whether or not a particular entry has an attachment (marked by an attachments attribute when one is added). I have done some investigation and I believe the FRFR3 (File Repository) table may keep record of this change, but the change would not be directly linked to the form in question. That said, if an employee experiences another change or we perform a full import against the table, the new image will still be picked up when retrieving the changed user, so the above only affects cases where only the photo has been updated.

Attached is a screenshot of the current chris21 software I have been developing and testing against.

Regards,

Matt

Further work currently awaiting reply.

Attached response from Daniel Jach of Frontier

Writing has been implemented. This proved to be somewhat involved, as similarly with the import process, a separate table needs to be written to in the case of attachments. Also, in order to properly use binary types, Identity Broker v3.0.6 must be patched with new Unify.Framework.Value and Unify.Framework.Adapter.LDIF changes, and the FIM adapter also requires updating. In other words, v3.0.6 of the chris21 connector would require a Identity Broker Service v3.0.6 Patch 3, and Identity Broker for Microsoft FIM v3.0.1.

As specified by Frontier, image updates require the existing image to be deleted, and a new one added. Because of this, unlike other connector attributes that are overwritten on every save attempt, attachments will only be updated if there is a difference between what exists in the Identity Broker connector entity repository and the entity that is being saved to chris21. In order to accommodate this, the communicator configuration takes an "attachmentFileExtension" attribute which specifies the file extension for created attachments - by default this is "jpg" if none is specified. The file name of the new attachment will be a combination of the first key of the form (eg. detnumber) and the file extension, eg. 102974.jpg

The following writing tests have been confirmed using the changes to the chris21 connector:

  • Updating an existing attachment from a user
  • Updating users with no change to the attachment
  • Updating users with no attachment
  • Adding an attachment to a user
  • Deleting an attachment from a user
  • Adding and updating the attachment at the same time as performing other updates on a user
  • Handling of attachment sizes that are lower and greater than the chris21 segment size for attachments to verify the effects of streaming are properly emulated

Outstanding work:

  • Investigation of EAI detection of attachment updates that are not adds or deletes, as described in an earlier comment
  • Documenting how the connector performs these operations under the internal IdB for Chris21 space

Investigation revealed that changes to attachments result in EAI change records that contain the file reference value of the item that has changed, and not the associated entity (eg. we can see that a file has changed, but not that it is an attachment relevant to the details or address form, for instance). As such, it was decided that v3.0.6 would note this as a limitation. That said, a polling import will successfully pick up an image change if another change is made to the form as well.

The function of the connector has been documented at INTIDBCHRS:Connector Development so as to assist further development on the connector, as well as to share the knowledge of how the connector functions.

The requested functionality has been added to the connector. Note that should anyone require this feature, the Identity Broker service and FIM adapter must also be updated with relevant patches.

Please confirm resolution when appropriate.

Connector was configured to prevent fields that are not the "DefaultAttachment" field from using the binary type. Since the file repository was found to be another table and direct connection may be possible, this check should be removed. Reopening

Above change made. Issue resolved.

Closed - confirmed again in v3.0.6.2