I'm importing business units and their addresses from SQL and exporting them via an XMA. Because each business unit can have multiple addresses, I have one MA for business units, and another MA for addresses - using a table plus a multi-value table. The system to which my XMA sends data does not care about addresses on their own. Whenever an address changes, I send the new address details within an XML object representing the business unit. For this reason, I'm hoping to have a replace action triggered in my ExportEntry method for a business unit object, whenever the addresses change (or at least when one is added or removed). The business unit object contains a multi-value reference attribute for addresses. I've included this multi-value attribute for export, in the attribute flow of my XMA. I'm not seeing a replace action, despite the preview showing an "add" for the addresses attribute in the export attribute flow. Is this strategy expected to work? If not, then the alternative would be to manually extract the related business units from FIM to send to the downstream system, whenever a replace action is received for an address object.

From your description, I don't really get what your setup looks like. If business units and addresses are contributed by separate MAs, what is the process to manage the multi-valued addresses attribute of a business unit? This is basically the same architecture as groups and the member attribute. You can't have referencing and referenced objects in separate connector spaces. I belief, there is something missing in your description. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks for the response Markus. Apologies for the delay in responding. Yes it is the same architecture as groups and membership. The process for managing the addresses attribute was going to be via the attribute flow of the XMA. Being a multi-value attribute, I had to recreate the XMA as a key-value pair format, rather than a CSV format. However, this did not trigger a replace action whenever a new address was created in the data source. I've resolved this by reverting to a CSV format XMA and "manually" exporting a business unit from my XMA whenever an action is received for a related address. Could you clarify what you mean by this statement... "You can't have referencing and referenced objects in separate connector spaces." ...isn't it typical to use a separate MA (with table & multivalue table provided) for each of the multi-value attributes that may be recorded against a business unit (or user)?

If Britta Simon has a manager attribute that points to Jimmy Bischoff, Britta and Jimmy must be in the same connector space to keep the reference in tact: If referencing and referenced object are not in the same connector space, the referential relationship can't be resolved by the synchronization engine and is therefore broken. For more details, see Design Concepts: About Reference Attributes. To process multi-valued attributes, you need to go back to an AVP file. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks again Markus. The documentation confirms that an object can reference another object of a different type. ie. a member can reference a group. I believe I'm not referencing objects in a different connector space because I have configured a join for the business unit and a projection for the address. The data source provides a primary and secondary table containing addresses, business units and the relationship between the two. In this structure, should a change to an address cause any outbound synchronization event for the business unit object? I guess not. The fact that the target system does not want to receive address objects on their own (it wants to receive business unit objects containing addresses) presents a special case that requires extra coding in my ECMA as described in my work-around above. Does this sound right?

Barry, I'm afraid, your description so far is a bit confusing. "Because each business unit can have multiple addresses, I have one MA for business units, and another MA for addresses - using a table plus a multi-value table." This sounds like you are having two source MAs - one for the referencing objects (business units) and one for the referenced objects (addresses) - is this correct? If so, you can't process reference attributes this way. The business unit objects and the address objects must be in the same connector space. Here is an example for the flow inside the synchronization engine in case of a group: Yes, the referenced objects can have a different type as the referenced objects. Moreover, does the SQL MA require a specific structure for multi-valued attributes. You can find more details on this in "Synchronizing SQL Server Objects to Active Directory" Since it is not clear, whether your setup for the multi-valued attribute is OK, it is hard to give you an answer regarding your ECMA. I would suggest solving the issues separatley. To test your ECMA, it is probably better to actually use an ADMA with a group that has members as source. That way, you can see how things should work. For the SQL setup, you must follow the instructions for the structure outlined in the linked document above. Cheers, Markus Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Hi Markus, thanks for your patience. Yes I have two source MAs. One for business units and another for their addresses. So reference attributes don't work this way, even if I join to both the business unit and the addresses in the 2nd MA? I had thought this would create both objects in the connector space and allow the references to work. I understand what you're saying about how to structure multi-value attributes. And I understand the description in the document you linked to above. Does this mean that the Mutlivalue Table nominated in the MA database configuration should contain all multi-value attributes related to the primary objects? ie. If a user has a multi-value attribute for groups, and another multi-value attribute for roles, then the Multivalue Table should contain all the groups and roles related to the users? Because previously I would have had 3 MAs representing this. One for users, another for their groups and another for their roles. This can, and should be done all in one MA?

It must be done with one MA. Cheers, MarkusMarkus Vilcinskas, Knowledge Engineer, Microsoft Corporation

Thanks Markus. Things are looking a lot better now that I'm using just one MA for all related objects.