• Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 1.0
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-13515create local Rice environment
      KULRICE-2315Implement caching of data to the IdentityManagementService implementation
      KULRICE-13327IT Failure PostProcessorTest in CI, passes locally
      KULRICE-13612revise/simplify local Rice install guide
      KULRICE-9285AccountManagerMaintenanceDocumentTest fails with NPE locally and in CI with unable to get class for unknown documentTypeName 'AccountManagerMaintenanceDocument'
      KULRICE-13671Create local testing environment
      KULRICE-7258Implement caching on ExtensionRepositoryService
      KULRICE-7354Standalone server is attempting to load remotable attributes locally
      KULRICE-6885Rice Dev2: Error with user cache?
      KULRICE-7533KualiPropertyMessageResources does not cache messages
    • Rice Module:
    • Application Requirement:
      KFS, KC, KS, Rice


      We can not assume that potentially external identity management systems will forever provide all users that ever existed to the system. As such, the PersonService (which is the contact point for all user lookups and references) must cache data retrieved from the external IdM system locally within Rice so that, if a user is deleted externally, references to that principalId that may exist within workflow and other database tables can still be resolved.

      Create KR_KIM_PERSON_CACHE_T. Add a column for each main data element on the Person interface that does not represent a derived value. The table will be keyed by principal ID and also have a timestamp as to the last

      Update the person service to attempt to pull person information from the IdentityManagementService. But, if not there, pull from the cache and populate a PersonImpl object. However, if the user was found in the IdM, then the record in the database would be updated.

      Roles and groups do not need to be cached. If they are not in the IdM system, we can assume that they no longer have any permissions.

      Another possibility is for the PersonService to be given a refresh period before which it will pull a given person from the cache instead of calling the IdM service. This would require an in-memory cache of principal ID->load time mappings. (This could have a WeakReference to the actual PersonImpl object instead.)

      The above may be necessary to prevent updating of the cache table upon every request for a person.



          • Assignee:
            Jonathan Keller
            Jonathan Keller
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created:

              Structure Helper Panel