Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-11052

Admin UI Mappings page load delay on system?_action=test REST call


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: OpenIDM 6.0.0, OpenIDM, OpenIDM, OpenIDM
    • Fix Version/s: 6.5.0
    • Component/s: Performance
    • Target Version/s:
    • Verified Version/s:
    • Story Points:
    • Sprint:
      OpenIDM Sprint 6.5-3
    • Support Ticket IDs:


      The Admin UIĀ calls the system?_action=test endpoint when loading the Mappings page and this is called once per mapping defined within sync.json by the getMappingDetails function within ConnectorUtils.js.

      The downside of this is that the system?_action=test call will perform a test on every configured connector (LDAP, CSV etc) and this will be repeated for every mapping in place (e.g. LDAP -> Managed, Managed -> LDAP, CSV -> Managed, Managed -> CSV would be 4 calls to the system?_action=test endpoint). This means that any latency in the response to the test call is multiplied by the number of mappings and the page(s) do not render until the calls are complete - in the support ticket attached, the customer sees the page load after 30 minutes.

      The code performing the call to the system?_action=test endpoint is within ConnectorDelegate.js:

      obj.currentConnectors = function () {
      var deferred = $.Deferred(),
      promise = deferred.promise();
      if (obj.connectorDelegateCache.currentConnectors) {
      } else {
      url: "?_action=test",
      type: "POST"
      }).then(function (result) {
      obj.connectorDelegateCache.currentConnectors = result;
      return promise;

      Which is itself called from several places in the UI, but specifically for this scenarion, from ConnectorUtils.js:

          obj.getMappingDetails = function (sourceName, targetName) {
              return ConnectorDelegate.currentConnectors().then(function (connectors) {
                  var details = {};
                  details.targetConnector = _.find(connectors, function (connector) {
                      return connector.name === targetName;
                  }, this);
                  details.sourceConnector = _.find(connectors, function (connector) {
                      return connector.name === sourceName;
                  }, this);
                  if (targetName === "managed") {
                      details.targetIcon = obj.getIcon("managedobject");
                  } else if (details.targetConnector) {
                      details.targetIcon = obj.getIcon(details.targetConnector.connectorRef.connectorName);
                  } else {
                      details.targetIcon = obj.getIcon("missing");
                  if (sourceName === "managed") {
                      details.sourceIcon = obj.getIcon("managedobject");
                  } else if (details.sourceConnector) {
                      details.sourceIcon = obj.getIcon(details.sourceConnector.connectorRef.connectorName);
                  } else {
                      details.sourceIcon = obj.getIcon("missing");
                  details.sourceName = sourceName;
                  details.targetName = targetName;
                  return details;

      The getMappingDetails function above is called from two places in the UI:


      Where the MappingListView.js is performing the specific loop which is causing this problem:

                      _.each(_this2.data.mappingConfig, function (sync) {
                          sync.targetType = this.syncType(sync.target);
                          sync.sourceType = this.syncType(sync.source);
                          mappingDetails.push(connectorUtils.getMappingDetails(sync.sourceType, sync.targetType));
                      }, _this2);

      This should be possible to solve by moving the call to the currentConnectors() function outside of the loop within MappingListView then passing the content of it's response to the function - I expect the same change would be needed for MappingBaseView.js too.


          Issue Links



              • Assignee:
                jason.browne Jason Browne
                becky.maund Becky Maund
              • Votes:
                1 Vote for this issue
                7 Start watching this issue


                • Created: