Within the portal every change made to any object will be processed via the FIM Portal's workflow engine and these requests can very quickly become unmanageable during the initial load process.
We recently had a project where we had to import 70,000+ objects into the FIM Portal and the initial load generated 640,000 requests even though we limited the MPR's and workflows that applied during initial loading. This firstly makes it hard to find a specific request, and also slows the performance of the web components down when performing a full search of requests (even causing time out issues in some cases).
In order to limit this from occurring we generally reduce the time that FIM Portal keeps completed request in the Portal before archiving them. The default retention period that requests are retained is set to 30 days. This means that if you generate 200,000 request this week, 700,000 the next week you would have to live with an additional 900,000 requests until the request reach an age of 30 days. You can see how this can become a problem during initial loading as it would:
- Slow down portal request searches for this time
- Put an additional storage load on you SQL database ( we had to extend the storage to over 2TB at one client)
- Put a strain of the index file ( we had to rebuild the index file numerous times)
This should be done prior to starting the initial load, as doing the change after the fact does not change the retention age on completed requests, but only those generated after the change. It should also be noted that these requests are archived and not deleted, but fall outside the scope of search-able requests in the FIM Portal, and can be retrieved via SQL queries or reporting tools.
A well planned initial load can save you many headaches and will contribute to a successful deployment.
For more information on FIM best practises navigate to the following link: