keil0008 Absent Member.
Absent Member.
2079 views

Discarding transaction because entry was deleted

Hi All,

I have an issue with the Google Apps driver. Here is the entirety of the level 3 trace when I try to migrate an account using iManager and the Google Apps driver.

[09/07/18 09:47:09.218]:IDM4GMAIL ST:Start transaction.
[09/07/18 09:47:09.218]:IDM4GMAIL ST:Discarding transaction because entry was deleted.


The association state on the user object changes to Migrate from Processed.

If I delete the association from the user account, I can migrate the account successfully and a match is found. Any subsequent migrate results in the condition above. This is happening to multiple user objects.

Google driver is version 4.1.1.5.

Any advice appreciated.

Thanks
Adam
Labels (1)
0 Likes
28 Replies
ukrause Super Contributor.
Super Contributor.

Re: Discarding transaction because entry was deleted

Hi Adam,

this sound really odd. Unfortunately I don't have an answer on this. I would open an incident to get support involved.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

Hi Adam,

Strange thing...
Event on subscriber channel suppose to start similarly for any driver.

Could you increase you trace level to 5-10 and post the trace here?
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

On 9/7/2018 3:44 PM, al b wrote:
>
> Hi Adam,
>
> Strange thing...
> Event on subscriber channel suppose to start similarly for any driver.
>
> Could you increase you trace level to 5-10 and post the trace here?


The code path you seem to be hitting is an optimization item, where if
there is an event in the cache, but the object itself is deleted, should
you process it? Clearly not. What would processing it do? The object is
gone. Sure you could have a use case where you might, but in general no.

So why does the engine think it is deleted?

Perhaps some odd kind of permission issue? (UNlikely, you would have
gotten a 672 error in trace then).

Maybe a higher level of trace will show more info.


0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

If object really deleted, it makes sense (nothing to process), but how iManager shows association for "deleted" object?


The association state on the user object changes to Migrate from Processed.


>Perhaps some odd kind of permission issue? (UNlikely, you would have gotten a 672 error in trace then).
Permission? I don't think so...
Usually driver security equal to admin.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

On 9/7/2018 4:44 PM, al b wrote:
>
> If object really deleted, it makes sense (nothing to process), but how
> iManager shows association for "deleted" object?


Right, the oddity of the situation.


>>
>> The association state on the user object changes to Migrate from
>> Processed.

>
>> Perhaps some odd kind of permission issue? (UNlikely, you would have

> gotten a 672 error in trace then).
> Permission? I don't think so...
> Usually driver security equal to admin.

Usually, but not always. Worth asking, I too doubt it however.

0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

On 09/07/2018 03:24 PM, Geoffrey Carman wrote:
> On 9/7/2018 4:44 PM, al b wrote:
>>
>> If object really deleted, it makes sense (nothing to process), but how
>> iManager shows association for "deleted" object?

>
> Right, the oddity of the situation.


Events go through the TAO file, and are only cleaned out when they are
processed in some way or the cache is deleted (e.g. when the driver config
object is disabled). As a result, it is easy to think of situations where
a now-deleted object may still be in a TAO file, but that does not match
with the details we have been given where presumably nothing was in the
TAO file, then ONLY a migrate of one object happened, and then the trace
message showed up. Maybe that is what we are assuming, but is not really
the case.

When was the object with the association created? Not when do we think it
was created, but what is its creation timestamp as reported by eDirectory?


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

al b wrote:

> If object really deleted, it makes sense (nothing to process)


unless it's a <delete> event, maybe...? 😉

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

I guess I would need to test to see if anything has changed with the
latest engine, but if it is a delete sans association then I think even
then that would make sense. There is little use in processing a delete
for something sans association since in theory it is not linked to the
application anyway.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

ab wrote:

> I guess I would need to test to see if anything has changed with the
> latest engine, but if it is a delete sans association then I think even
> then that would make sense. There is little use in processing a delete
> for something sans association since in theory it is not linked to the
> application anyway.


Yes, unassociated deletes are useless for syncronization, no object in IDV, so
no way to match it against an app side object. On the publisher those are
stripped after event transform processing, IIRC, don't they even show on the
subscriber at all? I could think of some use cases in business logic driver
where unassociated deletes might be of interest.

Would be great if delete events would (optionally) contain the attribute values
of the object when it was deleted, then we'd have a chance to still match and
delete (and clean up selectively) on the app side, too. This would make a
really really nice enhancement (which IIRC has been requested already several
times) - ...Tom? 😉

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)
______________________________________________
https://www.is4it.de/identity-access-management
0 Likes
Knowledge Partner
Knowledge Partner

Re: Discarding transaction because entry was deleted

lhaeger;2487338 wrote:
ab wrote:

> I guess I would need to test to see if anything has changed with the
> latest engine, but if it is a delete sans association then I think even
> then that would make sense. There is little use in processing a delete
> for something sans association since in theory it is not linked to the
> application anyway.


Yes, unassociated deletes are useless for syncronization, no object in IDV, so
no way to match it against an app side object. On the publisher those are
stripped after event transform processing, IIRC, don't they even show on the
subscriber at all? I could think of some use cases in business logic driver
where unassociated deletes might be of interest.

Would be great if delete events would (optionally) contain the attribute values
of the object when it was deleted, then we'd have a chance to still match and
delete (and clean up selectively) on the app side, too. This would make a
really really nice enhancement (which IIRC has been requested already several
times) - ...Tom? 😉

--
http://www.is4it.de/en/solution/identity-access-management/

(If you find this post helpful, please click on the star below.)


<delete> events show up on the Subscriber, associated or not. They're discarded at the end of the event transform, if I recall correctly. Trace message something like "discarding delete event on unassociated object".
0 Likes
keil0008 Absent Member.
Absent Member.

Re: Discarding transaction because entry was deleted

Apologies for the delayed response. I have enabled a level 10 trace as seen below. Note, the same config is running in our UAT environment with no problems.


[09/11/18 15:40:13.859]:IDM4GMAIL :Trace Level changed to 10
[09/11/18 15:40:33.400]:IDM4GMAIL ST:Start transaction.
[09/11/18 15:40:33.400]:IDM4GMAIL ST:type(resync-entry)entry-id(4) dn(null) class-id(-1) class-name(null)
[09/11/18 15:40:33.400]:IDM4GMAIL ST:Discarding transaction because entry was deleted.


EDIT: Obviously the curiosity is that the dn=null. Any idea what would cause this?
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.