Hi everybody, Since I'm new to FIM, I have a relatively simple question: I would like to provision several objects to the FIM portal from external HR text-files. Those objects are employees, positions, jobTypes and OU's. I started off with the employees, the import went ok - now though I have a problem concerning the import and linkage of the (newly created) object type 'position'. For the employee instances, I defined an attribute "Assigned Position Key" and would like it to be linked to the attribute "PositionKey" of the respective position-instance. How do I do that? Furthermore, I would like to know how I can see (and click) links in the Portal. For example, I have already successfully linked the attribute SuperiorPositionKey (of object position) to the respective position attribute "positionkey", simply by defining the former attribute as a reference. Although the link is perfectly visible in the metaverse object properties, the whole value (and thus the link itself) is not transported to the portal. Thank you already in advance for your help and support.

Hi, If the post is too random or unclear, meaning for an answer additional information is needed, please let me know! Thanks again for your help.

Ahh, you can't import lookup tables. In order to bring in data that exists in lookup tables (like positions), you need to dereference this data through a view such that the decoded value appears in the single object that the FIM Sync engine loads. For all intents and purposes, the data you import and export must be "flat". Now, within the portal, you could create customized RCDC's that have dropdown boxes which contain the postiion data, but essentially this is just a UI artifact, the data is still saved "flat" in the object. Your attempt to use references in either case won't work for what you are intending. References are meant for chasing relationships between entities like Manager, Secretary or when used in groups to support multi-valued lists where the group members reference the user objects. It is not possible for one attribute to inherit or lookup the value in another object; however, this capability could be coded to some degree within the portal by writing custom Workflow that would issue a lookup and return a value, but still you'd be saving the data back to the object directly and not storing a pointer. Hope that helps.Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

Hi, first of all - thanks for the reply, Brad! Secondly, to be honest, I didn't fully understand your answer. It occurred to me that I might have been a little unclear in the problem description. Now, I do have a text file with user data. I also have a management agent that provisions this data as objects of type user to the FIM portal. Then, I do have a separate text file with position data. I am also provisioning those through a separate MA as individual objects of (a newly created) type position. With the import, I only have minor problems like configuring the precedence or being able to view all configured attributes in the portal. The main area of concern though is the following: Each object type has its own anchor/unique ID through which it can be identified. For the object user, this attribute is "EmployeeID". For all instances of the object "position", it is "PositionKey". A user instance has an attribute "AssignedPositionKey" that holds a String value (a string of digits, to be exact). When comparing manually in the text files, this value is the same as the "PositionKey" attribute value of an instance of the object position. It would now somehow like the user object to be linked to the respective position object. User + EmployeeID +… + AssignedPositionKey linkage between the two Position + PositionKey +… + SuperPositionKey I figured I would have to do that via the attributes whose value they both have in common, "AssignedPositionKey" and "PositionKey". This linkage should be configured in a way that allows me to view details of a position instance by clicking on the positionKey-value of a user instance in the portal. As far as I understood you, a lookup is not possible meaning that I cannot provision users with a blank "AssignedPositionKey" attribute a get the value from the position instance. As I redefined earlier, both attributes have their own value stored (although those are the same digits). Does that still mean my problem cannot be solved by "conventional means" but rather by a custom workflow? For the reference examples you explained, I see that there's the possibility: For an attribute "SuperiorPositionKey" of an instance of the object position, it is possible to reference to the anchor of another instance of type object which is the attribute "PositionKey". As far as I know, this only works for several instances of the same object type though, right? The only question was how I can provision the flow mentioned above to the portal since it is clearly visible (and clickable) in the Metaverse but non-existant in the portal. Does that work with a custom RCDC? If yes, how could it be configured? Thanks a lot for your help!

Sorry to bother again but it would be really nice if somebody felt obliged to respond to the still unanswered question... time is not on my side right now ;) Thanks a lot!

i believe what Brad saying is that FIM doesn't "join" like that given two tables/object type. You shouldn't treat the object types like SQL table. The only join possible is by reference attribute. in your case, your Position object will be without PositionKey, and the Employee would have a reference attribute pointing to different position object.

Thanks for your quick reply! How do I point the reference attribute to the position object, both in the frontend and, more importantly, in the sync service manager when provisioning the data?

again, nobody's got any ideas?

Well I am just learning about FIM schemas myself so the following is speculation. Perhaps others can comment… It appears that references between different object types can travel between the sync engine and the portal because you can flow group membership back and forth. Group membership is a multivalued reference attribute on the group object that references user objects. Given this you should be able to flow other types of references between the sync engine and the portal. The trick is you will have to flow references and not key values. This means that you will have to have them as references in the Metaverse (sync engine) and in order to have objects reference each other in the Metaverse, they need to be sourced on the same management agent. You can’t feed objects in from one management agent and have them refer to objects in another management agent. (As Brad said there are no lookup tables.) So you will have to import all of your object types using a single management agent. This is possible with several of the management agents. The easiest format to play with is probably the attribute value pair MA. I would try importing your data from a single MA and make sure the sync engine recognizes the references as true references. You can test this by going into “Metaverse Search” and examining the reference attributes of your objects. If an attribute value shows up as a link and when you click on that link you open another object, you have successfully imported object references into the sync engine. After you have verified this, create the appropriate objects in the FIM portal, map them to the objects in the sync engine, set up the attribute flow rules for both objects and give it a shot. Be sure to flag the reference attributes as "reference". My guess is that this would work. For an example of an attribute value pair text file that holds two objects with links, see below. The file defines 4 users (Rex, Joe, Bill, and Cindy); it also defines 2 organizations (Fuzzy and Smooth); Rex and Joe are in the Fuzzy organization, Bill is in the Smooth organization, and Cindy is in both. Note that when you combine object types in source files for the sync engine, each object must have a key that is unique across all object types. Also note that when you set up the AVP MA you have to tell it what attribute contains the object type (in this case "object") and you have to tell it that attribure "org" is a reference type. Give it a shot and report back. id: 1 object: user name: Rex org: 2 id: 2 object: organization name: Fuzzy id: 3 object: organization name: Smooth id: 4 object: user name: Joe org: 2 id: 5 object: user name: Bill org: 3 id: 6 object: user name: Cindy org: 2 org: 3 As another example closer to your situation would be the following file which has three employees (Bob, Cindy, and Ted). Bob is a developer, Cindy is a tester, and Ted is a project manger). Bob and Cindy both report to Ted. The positions have salary ranges assigned to them and the employees have salary values (pretendt that the letters a-f are some sort of reasonable salary numbers.) id: 1 object: employee name: Bob position: 4 manager: 3 salary: a id: 2 object: employee name: Cindy position: 5 manager: 3 salary: d id: 3 object: employee name: Ted position: 6 salary: e id: 4 object: position name: developer salaryrange: a-b id: 5 object: position name: tester salaryrange: c-d id: 6 object: position name: project manager salaryrange: e-f

The short answer is that you need to solve this outside of FIM using a SQL Join. I tend to refer to this as "slipstreaming" data in from other sources. So, HR is your authoritative source but they may not actually own the Position table (chances are they do, but for illustrations purposes this could be any other data). If I understand correctly, you have a record coming in as: EmployeeID,Firstname,<etc>,AssignedPositionKey And a separate Position table with: PositionKey,PositionDesc,<data>,SuperiorPositionKey You need a create a view of the two tables that presents FIM with a single record that contains all of the data. FIM cannot have internal references to lookup tables so you need to flatten this as: EmployeeID, Firstname, <etc>, PositionDesc ...so that the position data like the text description shows up as an attribute on the person object. This would be a simple SQL inner join between the two tables using AssignedPositionkey = PositionKey to make the linkage. Once you have this view constructed, you would change your HR MA to use the data from this view instead and add he additional column(s).Brad Turner, ILM MVP - Ensynch, Inc - www.identitychaos.com [If a post helps to resolve your issue, please click the "Mark as Answer" or "Helpful" button at the top of that post. By marking a post as Answered or Helpful, you help others find the answer faster.]

You actually don’t have to flatten your data. You can keep the user and the position object types separate and flow them all the way from SQL through the sync engine and into the FIM Portal. Once in the FIM Portal you can bring up a user and look at their position attribute as a link; and then click on the position to get more information about it. I got all of this working in a lab environment and if there is interest I could probably write up a walkthrough. At a super high level you take two SQL tables, one for your users and the other for your positions and combine them together in a view. You point the SQL MA at this view and configure it to read in the data as separate object types (user and position). You then create a custom metaverse type and a custom resource type in the FIM Portal to hold this position object. You extend the user schema in the FIM Portal to include a position reference attribute. After all of this you set up the sync rules, adjust all the permissions needed to process the new schema and you end up with a “Position” attribute on user that you can click on to open up the Position object, which in turn will display the other attributes of position. Rex

Rex, How can you read the data as separate object types? I have to have two SQL MA to do it sharing the same sql view right? Thanks

You actually don’t have to flatten your data. You can keep the user and the position object types separate and flow them all the way from SQL through the sync engine and into the FIM Portal. Once in the FIM Portal you can bring up a user and look at their position attribute as a link; and then click on the position to get more information about it. I got all of this working in a lab environment and if there is interest I could probably write up a walkthrough. At a super high level you take two SQL tables, one for your users and the other for your positions and combine them together in a view. You point the SQL MA at this view and configure it to read in the data as separate object types (user and position). You then create a custom metaverse type and a custom resource type in the FIM Portal to hold this position object. You extend the user schema in the FIM Portal to include a position reference attribute. After all of this you set up the sync rules, adjust all the permissions needed to process the new schema and you end up with a “Position” attribute on user that you can click on to open up the Position object, which in turn will display the other attributes of position. Rex Right but there's no easy/native way to export your person object to say AD and have FIM dereference the position reference and give you the job title off the position object. Active Directory, 4th Edition - www.briandesmond.com/ad4/

How can you read the data as separate object types? I have to have two SQL MA to do it sharing the same sql view right? When you configure the SQL MA (and others), you can either specify that all records are of the same object type, or you can specify a particular attribute that indicates which object type each record is. Look at the "Object Type" button on the "Configure Columns" page on the MA properties. When you mix multiple object types you have one set of columns that contain all the attributes for all the object types. It is up to you to ensure that each record has the appropriate columns populated for the object type indicated.

Right but there's no easy/native way to export your person object to say AD and have FIM dereference the position reference and give you the job title off the position object. Agreed. You won't get the Sync engine to dereference the information natively. My point is that you don't have to flatten your data to pass references through end to end. The Sync engine does a brilliant job of maintaining and translating references and related objects between data sources. Dereferencing can be done in workflow code in the FIM Service, custom attribute flow in a stock MA, the export phase of your custom MA, or in your destination connected directory itself. You can also, as Brad said, flatten / dereference on the way in. Rex