• State Not Answered
  • Replies 5 replies
  • Subscribers 94 subscribers
  • Views 1600 views
  • Users 0 members are here
Options
Related

SAPUserInSApRole table question

sergei shvets
over 2 years ago

Working with 8.1.2 identity manager's SAP R/3 connector. we have a use case where SAP role assignments have been imported from SAP client to 1IM with XOrigin = 1 and need to be converted to IT Shop orders. Initially, OOTB method has been used, CreateITShopOrder, it would perform a conversion, however for some role assignments it would not work correctly, as it would incorrectly set ValidFrom dates, wipe out DisplayValue or even create duplicate assignments. Because of that, we have written a custom script that would perform the conversion using a bag and FillOrder method, this approach works well. However, we have noticed unexpected behavior.

For a case when one of the role assignments has already been converted using CreateITShopOrder method, but exact same user still has role assignments that need to be converted, we are seeing unexpected behavior by 1IM. When we convert an assignment with XOrigin = 1, using a script, it works correctly, however for previously converted assignments that were completed via CreateITShopOrder, 1IM triggers stored procedures that would remove the assignment and then create a brand new assignment. For example,  user VMANURI has 3 SAP role assignments:

1) XOrigin = 2, DistinguishedName = CN=VMANURI,OU=Z_INVENTORY_REPORTS,OU=2021-08-02,OU=9999-12-31,O=UserInRole,DC=950,DC=00,DC=BHD, this assignments was converted to IT Shop using CreateITShopOrder 

2) XOrigin = 3, DistinguishedName = CN=VMANURI,OU=YS_CTS_DEVELOPERS,OU=2019-02-05,OU=9999-12-31,O=UserInRole,DC=950,DC=00,DC=BHD, assignment converted to IT Shop using script

3) XOrigin = 1, DistinguishedName = CN=VMANURI,OU=Z_SPACE_PRODUCTIVITY,OU=2019-02-05,OU=9999-12-31,O=UserInRole,DC=950,DC=00,DC=BHD, assignment has not been converted

When we use a script to convert assignment #3, it works correctly, we see correct PWO entry and assignments is updated in SAPUserInSApRole table. However, 1IM triggers stored procedures for SAP role assignment that we are not doing any action on::

QBMDBQueueProcess: handle object delete for object type SAPUserInSAPRole   and   QBMDBQueueProcess: fire event Assign for object type SAPUserInSAPRole , these two stored procedures result in role assignment #1 getting deleted and exact same assignment re-created with a new UID value.

Same exact behavior happens, if we update XOrigin from 3 to 2 for role assignment #2, 1IM would again re-create role assignment #1.

We are puzzled as to why this triggers every time for role assignment #1 when no event/action is made for it. Are we missing something, for example maybe some bad data in PWO table for role assignment #1 that could be forcing 1IM this unwanted behavior or could this be support related issue?

After doing trace logs, we are seeing that role assignment gets passed with 'DEBUG (ObjectLog ) : SAPUserInSAPRole.XMarkedForDeletion = 1' but it doesn't make sense as to why 1IM believes that role assignment #1 needs to be dropped and then re-created every time.

ChangedProperties: XMarkedForDeletion
    IsChanged: True
    IsDifferent: True
    Values:
        - ChangedDateTime: <null>
        - DisplayValue: 9e44e3c0-67f1-4a9d-9f15-5be900282a39<Key><T>SAPRole</T><P>436abd1f-5598-4e46-9d11-f458ffa0148e</P></Key> (8/2/2021 - 12/31/9999)
        - DisplayValue[O]: 9e44e3c0-67f1-4a9d-9f15-5be900282a39<Key><T>SAPRole</T><P>436abd1f-5598-4e46-9d11-f458ffa0148e</P></Key> (8/2/2021 - 12/31/9999)
        - DistinguishedName: CN=VMANURI,OU=Z_INVENTORY_REPORTS,OU=2021-08-02,OU=9999-12-31,O=UserInRole,DC=950,DC=00,DC=BHD
        - DistinguishedName[O]: CN=VMANURI,OU=Z_INVENTORY_REPORTS,OU=2021-08-02,OU=9999-12-31,O=UserInRole,DC=950,DC=00,DC=BHD
        - IsCurrentlyActive: True
        - IsCurrentlyActive[O]: True
        - ObjectKeySAPRole: <Key><T>SAPRole</T><P>436abd1f-5598-4e46-9d11-f458ffa0148e</P></Key>
        - ObjectKeySAPRole[O]: <Key><T>SAPRole</T><P>436abd1f-5598-4e46-9d11-f458ffa0148e</P></Key>
        - RiskIndexCalculated: 0
        - RiskIndexCalculated[O]: 0
        - UID_SAPUser: 9e44e3c0-67f1-4a9d-9f15-5be900282a39
        - UID_SAPUser[O]: 9e44e3c0-67f1-4a9d-9f15-5be900282a39
        - UID_SAPUserInSAPRole: 6F75FCC2-9713-4CE6-9A09-9F785927683F
        - UID_SAPUserInSAPRole[O]: 6F75FCC2-9713-4CE6-9A09-9F785927683F
        - ValidFrom: 8/2/2021 12:00:00 AM
        - ValidFrom[O]: 8/2/2021 12:00:00 AM
        - ValidTo: 12/31/9999 12:00:00 AM
        - ValidTo[O]: 12/31/9999 12:00:00 AM
        - XDateInserted: 8/2/2021 3:30:14 PM
        - XDateInserted[O]: 8/2/2021 3:30:14 PM
        - XDateUpdated: 8/2/2021 3:30:44 PM
        - XDateUpdated[O]: 8/2/2021 3:30:44 PM
        - XIsInEffect: True
        - XIsInEffect[O]: True
        - XMarkedForDeletion: 1
        - XMarkedForDeletion[O]: 0
        - XObjectKey: <Key><T>SAPUserInSAPRole</T><P>6F75FCC2-9713-4CE6-9A09-9F785927683F</P></Key>
        - XObjectKey[O]: <Key><T>SAPUserInSAPRole</T><P>6F75FCC2-9713-4CE6-9A09-9F785927683F</P></Key>
        - XOrigin: 0
        - XOrigin[O]: 0
        - XTouched:
        - XTouched[O]:
        - XUserInserted: SAP_ZUserInSAPRole
        - XUserInserted[O]: SAP_ZUserInSAPRole
        - XUserUpdated: Synchronization
        - XUserUpdated[O]: Synchronization

Any help is appreciated.

Thanks,

Sergei

Parents
  • 0 over 2 years ago

    It is unclear what your script does, but if you set XOrigin=0 somewhere on the way, this will be recognized as a deletion and the DBQueue will act accordingly.

  • 0 over 2 years ago in reply to Christian Stevens

    Christian,

    Script is really simple, it doesn't set XOrigin to 0, again, script doesn't take any action or call any event for SAP role assignment that has already been converted via OOTB method. Also, keep in mind that unwanted behavior occurs even without execution of the script, for example, if we perform SQL update on role assignment with XOrigin of 3 and update it to 2, again not on the role assignment that has been converted via OOTB method but a completely different one, 1IM still triggers a deletion and creation of a brand new assignment on the SAP role assignment that has been converted via OOTB CreateITShopOrder method. Script that we are using is:

    Dim dbpwo As IEntity

            dbpwo = Session.Source.CreateNew("PersonWantsorg")

            Dim bag As New PropertyBag()

            bag.PutValue("uid_personordered", uidPerson)
            bag.PutValue("uid_personinserted", uidPerson)
            bag.PutValue("uid_Org", uidITShopOrg)
            bag.PutValue("Orderstate", "Assigned")
            
            bag.PutValue("OrderReason", "Assignment converted to IT Shop request automatically. Assignment is from the semi-automated process for SAP.")
            bag.PutValue("ObjectKeyOrdered", objectKeySAPRole)
            bag.PutValue("UID_ITShopOrgFinal", uidITShopOrg)
            bag.PutValue("UID_OrgParent", uidOrgParent)
            bag.PutValue("UID_OrgParentOfParent", uidOrgParentOfParent)
            bag.PutValue("ValidFrom", validFrom)
            bag.PutValue("ValidUntil", validUntil)
            
            bag.PutValue("DateActivated", DateTime.Now)
            bag.PutValue("OrderDate", DateTime.Now)

            dbpwo.CallMethod("FillOrder", bag)
            dbpwo.Save(Session)

    Thanks,

    Sergei

Reply
  • 0 over 2 years ago in reply to Christian Stevens

    Christian,

    Script is really simple, it doesn't set XOrigin to 0, again, script doesn't take any action or call any event for SAP role assignment that has already been converted via OOTB method. Also, keep in mind that unwanted behavior occurs even without execution of the script, for example, if we perform SQL update on role assignment with XOrigin of 3 and update it to 2, again not on the role assignment that has been converted via OOTB method but a completely different one, 1IM still triggers a deletion and creation of a brand new assignment on the SAP role assignment that has been converted via OOTB CreateITShopOrder method. Script that we are using is:

    Dim dbpwo As IEntity

            dbpwo = Session.Source.CreateNew("PersonWantsorg")

            Dim bag As New PropertyBag()

            bag.PutValue("uid_personordered", uidPerson)
            bag.PutValue("uid_personinserted", uidPerson)
            bag.PutValue("uid_Org", uidITShopOrg)
            bag.PutValue("Orderstate", "Assigned")
            
            bag.PutValue("OrderReason", "Assignment converted to IT Shop request automatically. Assignment is from the semi-automated process for SAP.")
            bag.PutValue("ObjectKeyOrdered", objectKeySAPRole)
            bag.PutValue("UID_ITShopOrgFinal", uidITShopOrg)
            bag.PutValue("UID_OrgParent", uidOrgParent)
            bag.PutValue("UID_OrgParentOfParent", uidOrgParentOfParent)
            bag.PutValue("ValidFrom", validFrom)
            bag.PutValue("ValidUntil", validUntil)
            
            bag.PutValue("DateActivated", DateTime.Now)
            bag.PutValue("OrderDate", DateTime.Now)

            dbpwo.CallMethod("FillOrder", bag)
            dbpwo.Save(Session)

    Thanks,

    Sergei

Children
  • 0 over 2 years ago in reply to sergei shvets

    By assisgning SAPRole PWOs to Persons, you are triggering a recalculation of all SAPRole memberships for the affected SAP account(s) on the whole client (DBQueue Task 'SAP User account memberships in SAP roles' takes only the SAP account as a parameter).

    Since all of your three examples are for the same SAP account, they are all recalculated when you trigger conversion of 3). This means all memberships are checked for plausibility and removed if there is 'no reason for them to exist'.

    XOrigin=2 means there must be an indirect assignment at the time of recalculation, or the membership gets removed. Don't ask me why, but XOrigin=2 is what happens when you order a SAProle directly through IT-Shop. There is no XOrigin=8 ("ITShop order") in this case.
    For 1) the UID_Person of the account  needs to still have an assigned PWO for that exact membership, or it gets removed 'at the next opportunity'.

    In your trace Log, it looks like your Synchronization (XUserUpdated) has changed the membership since it was created by OIM through the conversion. Maybe the data in the backend is not exactly the same as OIM expects it, which is why it gets deleted & recreated with correct (PWO) data. Maybe just a minor difference in one of the fields?

    Note: If your script is not removing the direct assignment flag (XOrigin=1), your memberships will result with XOrigin=3. This means the membership will not be removed when the PWO is unsubscribed, since the direct assignment flag will remain..

  • 0 over 2 years ago in reply to Christian Stevens

    Christian,

    Nothing changes for the assignment, as you see in the trace user re-creating the assignment every time 'SAP_ZUserInSAPRole', system marks the assignment for deletion and then re-assignment and only thing the system changes is the UID_SAPUserinSAPRole value. PWO entry for the assignment was created by the system via CreateITShopOrder method that is OOTB. This seems to be a bug as the system should not be trying non-stop re-creating the same exact assignment, we are trying to understand why exactly system thinks that it needs to drop and re-assign when system is the one that created PWO and SAPUserInSAPRole entries in the first place, more than that system keeps on re-creating it every time, nothing else touches that assignment.

    As far as XOrigin = 3, yes that is understood, there are two pieces one that creates PWO entry and portion that updates Xorigin to 2 which is why I am saying that regardless whether we only perform the first step or second step to update Xorigin via SQL, system still drops and re-assigns its own assignment, the question is why it does that and thinks that its own system generated PWO entry is invalid, well not even that if system thought that PWO entry is invalid it would still drop it only, correct? Instead we are seeing drop and re-assign of exact same assignment with only UID changing...

  • 0 over 2 years ago in reply to sergei shvets

    Did you manage to solve the problem?

    I'm having the same issue, when I execute the method CreateITShopOrder on SAPUSerInSAPRole entries. Request are created (exept for redundant assigment of SAP Role) but some of these Request trigger a delete and recreate assigment, with a different ValidFrom Date (one day before the ValidFrom Date of the deleted assigment) and no values populated, like the distinguished name. This behaviour causes object to be marked as outstanding after a synchronization because they do not exists in target. I disabled processes for this table to avoid any error on target system.