none
FIM-SQL ambiguous-import-flow-from-multiple-connector / already exists in management agent RRS feed

  • Question

  • I have a SQL table called transaction

    This table would have entries employeeNo , field1, field2 , field3 ,...
    I need to import the data from transaction and project unique Entries to FIM and AD
    The data in transaction table would get an entry every time there is an update for any field for employee


    Problem : 
    When I import the data with unique Records as shown in the table for Batch 1 .. The record gets provisioned to AD and FIM with no issue

    Asuming the next batch transaction were added Batch 2 as shown in the table 


    I get an error for ambiguty ambiguous-import-flow-from-multiple-connector. I need a module in which i read the data from sql MA and delete the respective entry from table. 
    For this structure I deleted the old records from batch1 and now I get error 

    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".
       at Microsoft.MetadirectoryServices.Impl.ConnectorImpl.Commit()
    The above error line number is provisioning code used to commit new connector for a MA when the number of connectors for the MA is 0.

    I know why the above error already exist is comming, however i want it to join and not make a new connector. Join Rules are in place for EmployeeNo for this SQL MA and other MA.

    I need to know if this kind of module can be implemented or not ? Where in I just read the transaction and next time update if already exist. 

    Let me know if any questions.

      trans_no employeNo field1 field2 field3
      1 Emp1 XyZ Abc 123
    Batch1 2 Emp2 AAA BBB 456
      3 Emp3 CCC DDD 789
       
      trans_no employeNo field1 field2 field3
      1 Emp1 XyZ Abc 123
      2 Emp2 AAA BBB 456
      3 Emp3 CCC DDD 789
    Batch2 4 Emp8 IIII GGG 2222
      5 Emp1 DDD WWW 123
      6 Emp2 GGGG HHHH 333
    I want transaction 5 & 6 to join with exisiting connector





    Thanks in advance :)


    • Edited by Muju_S Monday, December 14, 2015 11:18 AM
    Monday, December 14, 2015 11:17 AM

Answers

  • If you have a means of selecting which record is precedent among those connected then you could use manual precedence to allow multiple connectors from the transaction table to the Metaverse (see here https://msdn.microsoft.com/en-us/library/windows/desktop/ms696787(v=vs.100).aspx). This would still be a 1 to 1 scenario from the Metaverse to the FIM Service.

    It does however sound like you are trying to use FIM to do something it shouldn't really be doing. Can you make your transaction table only display one record per user? This would be ideal if none of the attributes from the other records will be used.

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 3:06 PM
  • The issue here is that you have multiple records for the same person in your table. This isn't really a scenario that FIM is well suited to handle. The best option here is to construct a view in your database that normalizes the data so you have one row per employee with the latest value for each field.

    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 4:17 PM
    Moderator
  • Thanks Brian for replying.

    I have created a view which selects unique user in the run. Now when the next batch comes in it gives an error 
    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".

    • Edited by Muju_S Monday, December 14, 2015 7:39 PM
    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 7:36 PM
  • Thanks Brian for replying.

    I have created a view which selects unique user in the run. Now when the next batch comes in it gives an error 
    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".

    - Mujeeb Shaikh

    Are you doing codeless provisioning or using a metaverse extension? 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 7:37 PM
    Moderator
  • Thanks for replying FIM-EN

    I will give a try with Merge / Replace functions and let u know. I have created a view which gives me unique record for one user. This removes ambugity error, however it is giving an error the 

    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".


    • Edited by Muju_S Monday, December 14, 2015 7:39 PM
    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 7:38 PM
  • MV Extension. I guess the join rule is failing somewhere. 

    Step1:

    TransactionIN (Selecting new records, if already exist join to MV entry and update it)

    Step2

    ADD to AD

    Step3

    Once AD account is created 

    Step4

    Acknowledge the IN record via OUT MA  and delete the TransactionIN entry

    Step5

    Goto Step1



    • Edited by Muju_S Monday, December 14, 2015 9:24 PM
    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 9:23 PM
  • This is normal in this case. You need to wrap your provisioning code in a try/catch block and swallow the ObjectAlreadyExistsException. Your provisioning code gets called before the Join. By swallowing the exception, the join will occur.


    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 9:27 PM
    Moderator
  • Is "MANAME" your ADMA or your TransactionOUT MA?

    If it's ADMA then I'd agree, it sounds like your TransactionIN MA hasn't joined to the MV entry properly, or your provisioning code is trying to provision the same user to AD more than once (if in you're provisioning code you're checking Connectors.Count() before trying to provision then it's very likely the join rule at fault).

    If it's TransactionOUT then you probably need to change your provisioning method - or at least the anchor, so that it can create more than one record per Metaverse entry (for example, you use trans_no in your TransactionIN table).

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Tuesday, December 15, 2015 8:50 AM

All replies

  • If you have a means of selecting which record is precedent among those connected then you could use manual precedence to allow multiple connectors from the transaction table to the Metaverse (see here https://msdn.microsoft.com/en-us/library/windows/desktop/ms696787(v=vs.100).aspx). This would still be a 1 to 1 scenario from the Metaverse to the FIM Service.

    It does however sound like you are trying to use FIM to do something it shouldn't really be doing. Can you make your transaction table only display one record per user? This would be ideal if none of the attributes from the other records will be used.

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 3:06 PM
  • The issue here is that you have multiple records for the same person in your table. This isn't really a scenario that FIM is well suited to handle. The best option here is to construct a view in your database that normalizes the data so you have one row per employee with the latest value for each field.

    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 4:17 PM
    Moderator
  • Thanks Brian for replying.

    I have created a view which selects unique user in the run. Now when the next batch comes in it gives an error 
    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".

    • Edited by Muju_S Monday, December 14, 2015 7:39 PM
    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 7:36 PM
  • Thanks Brian for replying.

    I have created a view which selects unique user in the run. Now when the next batch comes in it gives an error 
    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".

    - Mujeeb Shaikh

    Are you doing codeless provisioning or using a metaverse extension? 

    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 7:37 PM
    Moderator
  • Thanks for replying FIM-EN

    I will give a try with Merge / Replace functions and let u know. I have created a view which gives me unique record for one user. This removes ambugity error, however it is giving an error the 

    Microsoft.MetadirectoryServices.ObjectAlreadyExistsException: An object with DN "Emp1" already exists in management agent "MANAME".


    • Edited by Muju_S Monday, December 14, 2015 7:39 PM
    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 7:38 PM
  • MV Extension. I guess the join rule is failing somewhere. 

    Step1:

    TransactionIN (Selecting new records, if already exist join to MV entry and update it)

    Step2

    ADD to AD

    Step3

    Once AD account is created 

    Step4

    Acknowledge the IN record via OUT MA  and delete the TransactionIN entry

    Step5

    Goto Step1



    • Edited by Muju_S Monday, December 14, 2015 9:24 PM
    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 9:23 PM
  • This is normal in this case. You need to wrap your provisioning code in a try/catch block and swallow the ObjectAlreadyExistsException. Your provisioning code gets called before the Join. By swallowing the exception, the join will occur.


    Thanks,
    Brian

    Consulting | Blog | AD Book

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Monday, December 14, 2015 9:27 PM
    Moderator
  • Is "MANAME" your ADMA or your TransactionOUT MA?

    If it's ADMA then I'd agree, it sounds like your TransactionIN MA hasn't joined to the MV entry properly, or your provisioning code is trying to provision the same user to AD more than once (if in you're provisioning code you're checking Connectors.Count() before trying to provision then it's very likely the join rule at fault).

    If it's TransactionOUT then you probably need to change your provisioning method - or at least the anchor, so that it can create more than one record per Metaverse entry (for example, you use trans_no in your TransactionIN table).

    • Marked as answer by Muju_S Tuesday, December 15, 2015 7:13 PM
    Tuesday, December 15, 2015 8:50 AM