In this post I will show how to attach an HR data source to the FIM Sync Service, and then import data about employees into the FIM Portal.
Create the HR Management Agent
|The aim is to create a management agent for your HR data source. In this example I’m using a SQL database, but it could equally be CSV, SAP, Oracle or something else. The product Help tells you how to configure the prerequisites for each of these MA types.|
|We’re going to use a codeless sync rule to import data, so we don’t need a join or projection rule here.If you’re not using the Portal,you will need to configure this tab – see Creating a Management Agent|
|If using codeless sync you can also leave the flow rules blank for now, though you may find you need to revisit this tab if you want to created Advanced flow rules that aren’t currently possible with codeless. Note that it’s fine to use a combination of codeless and coded rules. See Advance Attribute Flow Rules.|
Create the Import Sync Rule
|Now go into the Portal and open the Synchronization Rules page from under the Administration menu. Create a new Inbound Sync Rule.|
|The rule matches an external object type with a Metaverse object type, via the selected MA.|
|On this page we specify how to identify that an object in the external system matches an object in the Metaverse. In this case we’ll use the employeeID, which we will also be flowing from this source.
Note I’ve also ticked “Create resource in FIM” which will cause an object to be automatically provisioned into the connector space of the FIM MA, ready to export to the FIM Portal.
|Finally we specify our import flow rules, which should be pretty self-explanatory. It’s a good idea to make use of functions such as Trim and ProperCase to make sure that your data comes into the Metaverse in a fairly consistent state. Also be very sure to flow in the identifying attribute you specified in the form above!|
|If you need extra Metaverse attributes to import your data to then you will have to go back to the Synchronization Service GUI and modify the Metaverse schema.|
Configure the Metaverse -> Portal Flows
|This is where it gets a bit odd. We’ve created HR -> Metaverse flow rules using a codeless Sync Rule created in the Portal, but to get the data from the Metaverse into the Portal itself we actually have to use old-style MA rules.
In The Synchronization Service GUI, open the properties of the FIM MA and open the Configure Attribute Flow page.
|Add the Export flow rules that will copy data from the Metaverse to the Portal.
If you need extra attributes in the Portal for your HR data then see then see this document on the Portal schema. You will need to refresh the schema on the MA, and select the new attributes in the Attributes tab before they will be available for the flow rules.
|To avoid permissions problems when your export data to the Portal, check the MPR “Synchronization: Synchronization controls users it synchronizes” and make sure that the account used by the Sync Service has the rights to update all required attributes. It’s easy to just give the Sync Service rights to all user attributes in this MPR, but it depends on your requirements and security rules whether you’d do this.|
Create the Run Profiles
|Create Import and Sync run profiles for the HR MA. Here I’ve created a single-step “Full Import and Full Sync” run profile.|
|For the FIM MA I need Import/Sync and Export run profiles.|
Finally – Make something happen!
|The first job you need to run is the Import/Sync on the FIM MA. In a freshly installed system you should see three objects being projected into the Metaverse. Inspecting these objects shows them to be the Administrator user, the Built-In Synchronization user, and the HR Import Sync Rule we created above.|
|Now you can Import/Sync the HR MA. You should see objects being projected into the metaverse, and also provisioned as Adds into the FIM MA. If you inspect some of these objects in the Metaverse you should see them populated with attributes from the HR data source.|
|Finally you are ready to export your HR data to the Portal.
Various errors can happen here, and they will mostly be connected to Portal schema (particularly check the Validation tabs in both attribute and binding definitions) or Portal permissions (check MPRs that apply to the Built-In Synchronization accout).
If you see nice “Adds” counting up here then things are good, and you’ll find users defined in the Portal. It may not be quick though – the first load of data into the Portal is not the most performant part of this platform.