A Subscription Event should be able to tell from where it is triggered

Remco_Reinking

Suppose there is a subscription on the event OnAfterDelete "Sales Line"
It should only execute the subscriber code when it is not being called from codeunit 80.
How would that be possible?

Is the only method to do this using the this nice trick from Vjeko?

http://vjeko.com/detecting-current-object-type-and-id-using-some-funky-net-interop/

Kishorm

@Remco_Reinking Great thinking about the stack trace - I agree that would be the way to go. You can create a function...

ExistsInStackTrace(ObjectType,ObjectID,FunctionName)

...and then you could use it for other stuff if you needed to

mohana_cse06

yes please. at present we have only RunTrigger as parameter

binilabraham

If I'm not wrong, the subscriber code will execute whenever a sales line deleted

Kishorm

@Remco_Reinking - I don't think this is possible. Even if you tried the Interop stuff in Vjeko's blog as I would have thought that would identify the object that the subscription function was in (or possibly the Sales Line table itself) - this is just a hunch though so it's worth trying out.

Remco_Reinking

@binilabraham : yes, and that is just the problem. I dont want to do run some code if the delete is triggered from CU80.
@Kishorm : It would be possible, but yes I agree, it is not easy.
This is an example of the stacktrace:


Best guess would be to look through the stacktrace, and to check if there is a line with CodeUnit80 OnRun.

If I gather the stacktrace and show it in the Error Message it shows:


So yes, maybe I'll give it a try.
Code would be something like this:

Kishorm

@Remco_Reinking Great thinking about the stack trace - I agree that would be the way to go. You can create a function...

ExistsInStackTrace(ObjectType,ObjectID,FunctionName)

...and then you could use it for other stuff if you needed to

Remco_Reinking

But I wonder what is the impact on performance, because it would be triggered per line deleted. Anyway, for now this is the only solution I guess.

Kishorm

I wouldn't expect a significant impact on performance as it's all CPU based code - no access to SQL tables.

You could also check the RunTrigger parameter first - so if this is TRUE then you know already that it's not being called from CU 80 and don't need to check the StackTrace

Marije_Brummel

Guys, this is not what events are intended to be used for. The idea about events is to have loosely coupled code from Microsoft that in theory would allow MSFT to replace Codeunit 80 with something else without breaking your code.

Remco, you need to rethink your business case.

Sog

How about you check if a sales invoice line exists related to the deleted sales line. Then you shouldn't have to (ab)use the stacktrace.

Remco_Reinking

@Mark_Brummel IF for whatever reason one wants to use this OnDeleteSalesLine event it should also be possible to skip it if it is triggered from the posting routine. That is my opinion. Loosely coupled, yes, but always with the version in mind were it is supposed to run on. So if Microsoft comes up with another posting routine, the events should also be updated according to this.

@Sog That is a good option, but it would definitely have an impact on the performance.

Kishorm

@Remco_Reinking wants to...

1) ...do something different depending on whether the line is being deleted from the posting codeunit or not - not unreasonable (standard NAV does some stuff slightly differently in CU 80 depending on whether it's called from the Inventory Pick/Put-away or not)

2) ...try to achieve this by only having code in an event, I.e without making changes to standard NAV objects such as codeunit 80 - again not unreasonable (this is the way we are being to told to do things these days)

Yes, he has come up with a creative solution - but is this really a bad thing?

Until someone comes up with a better solution, I think what has been suggested is quite reasonable

Kishorm

@Remco_Reinking - I think in pretty much most other cases the Sales Line DELETE method will be called with the trigger set to true, so would it work for your situation to just check the RunTrigger parameter and only run your code if that is TRUE?