0 Replies Latest reply: Jun 25, 2015 10:09 AM by Andrew Martinez RSS

    User Sync via API creates dupilicate user attributes

    Andrew Martinez

      Using the Qlik Repository Service API to trigger a user directory sync and the result is creating users with duplicate attributes with dates that say the attribute was created in the year 1753.

       

      The User Directory connector is going against a user view and a user attribute view within SQL server. The views do not at any point contain duplicate attributes.

       

      The user sync is being triggered via the Repository Service web API; specifically a POST to /qrs/userdirectoryconnector/syncuserdirectories.

       

      The result is user attribute data that looks like this:

       

      [ { id: 'c31775c1-0358-4b82-aff7-31e9e7ad6f75',                       
          createdDate: '1753-01-01T00:00:00.000Z',                          
          modifiedDate: '2015-06-25T13:46:06.773Z',                         
          modifiedByUserName: 'INTERNAL\\sa_repository',                    
          attributeType: 'email',                                           
          attributeValue: 'V1SErgrD_at_qlik_user_sync_file_drop@at.com',    
          externalId: 'V1SErgrD_at_qlik_user_sync_file_drop@at.com',        
          schemaPath: 'User.Attribute' },                                   
        { id: '71c87080-466e-4254-b779-8c6fd75a80ab',                       
          createdDate: '1753-01-01T00:00:00.000Z',                          
          modifiedDate: '2015-06-25T13:46:06.773Z',                         
          modifiedByUserName: 'INTERNAL\\sa_repository',                    
          attributeType: 'tenantAbbreviation',                              
          attributeValue: 'AT',                                             
          externalId: 'AT',                                                 
          schemaPath: 'User.Attribute' },                                   
        { id: '1612cfb3-f4c6-44f0-a273-bfbef333d587',                       
          createdDate: '1753-01-01T00:00:00.000Z',                          
          modifiedDate: '2015-06-25T13:46:06.773Z',                         
          modifiedByUserName: 'INTERNAL\\sa_repository',                    
          attributeType: 'tenantAbbreviation',                              
          attributeValue: 'AT2',                                            
          externalId: 'AT2',                                                
          schemaPath: 'User.Attribute' },                                   
        { id: 'b1cbd244-020f-4fdd-b12f-719d1c3f769e',                       
          createdDate: '2015-06-25T13:45:58.336Z',                          
          modifiedDate: '2015-06-25T13:46:06.773Z',                         
          modifiedByUserName: 'INTERNAL\\sa_repository',                    
          attributeType: 'tenantAbbreviation',                              
          attributeValue: 'AT',                                             
          externalId: 'AT',                                                 
          schemaPath: 'User.Attribute' },                                   
        { id: '81d25601-9ce4-4a5c-9609-cf78cf81e924',                       
          createdDate: '2015-06-25T13:45:58.336Z',                          
          modifiedDate: '2015-06-25T13:46:06.773Z',                         
          modifiedByUserName: 'INTERNAL\\sa_repository',                    
          attributeType: 'email',                                           
          attributeValue: 'V1SErgrD_at_qlik_user_sync_file_drop@at.com',    
          externalId: 'V1SErgrD_at_qlik_user_sync_file_drop@at.com',        
          schemaPath: 'User.Attribute' } ]                                  

       

      Note that the attribute 'tenantAbbreviation' with value 'AT' appears twice. So does the 'email' attribute with value 'V1SErgrD_at_qlik_user_sync_file_drop@at.com'. Each of those pairs has one that has a legitamate created date (i.e. '2015-06-25T13:45:58.336Z') but the other in the pair lists the create date as '1753-01-01T00:00:00.000Z'. The user will remain in this state until a future user sync is performed.

       

       

      Any ideas on why this would happen or a way to resolve it other than performing another user sync?