Event handler of inbound plug not called when plug fired by event handler

[ChrisPaine]

Hello All,

I have a rather bizzare problem, hopefully someone out there can figure out what is going on, as I'm rather stumped.

I have 2 views, A and B. They are linked by plugs, InA, InB, OutToA, OutToB. OutToB is linked to InB from A to B, OutToA is linked to InA from B to A.

There is an onActionLink in view A. Clicking on this triggers an action which calls the wdFirePlugOutToB method.

In view B some handling is done in the method onPlugInB, then wdFirePlugOutToA is called to change the displayed view back to A.

As far as the user is concerned they don't ever see view B. (this bit works perfectly!)

Now also in view A I have an event handler which handles a event from the component controller. It also calls wdFirePlugOutToB.

If I trigger an event in the component controller this event handler is called and the method called. However, when I put a breakpoint in the onPlugInB, flow never reaches here. Flow does get to the wdDoModifyView of view B but never to the inbound plug event handler.

Any suggestions as to what I might need to do? I would have thought calling the wdFirePlugOutToB method would ALWAYS trigger the linked event handler onPlugInB.

I am running NW04 SP18.

Thanks!

[Former Member · Accepted solution]

Chris,

To confirm:

<i>There is an onActionLink in view A. Clicking on this triggers an action which calls the wdFirePlugOutToB method.

In view B some handling is done in the method onPlugInB, then wdFirePlugOutToA is called to change the displayed view back to A.</i>

Does this means that ViewB is not shown to end-user during this?

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[ChrisPaine · Accepted solution]

Hi Valery,

Yes ViewB is never shown to the end user, when the navigation is working properly. My problem is that when the inbound plug doesn't fire, the user <b>does</b> see ViewB - which I don't want.

This code is very similar to that used in the pcui_gp code for the FPM.

I trigger what might seem useless navigation on jumping from one view to another and straight back again, but this seems to be the only way to display changes to dynamically assigned views in view container UI elements. Again - refer to the FPM code in pcui_gp.

I believe that the issue I am having might actually be related to the pcui_gp code, as the component and associated views I am building are displayed using the FPM, and the external input which is triggering the navigation which does not fire the plug is done by an event handled by the FPM. I think that possibly the FPM code is clearing the web Dynpro navigation stack somehow, so that the framework looses track of which plug should be called in ViewB. This is the only reasonable explaination that I can come up with. However, that said, I can't see anywhere in the FPM code where it might be doing this.

That all said, my original assertation stands, should it not be the case that <b>EVERY</b> outbound view navigation calls the corresponding inbound event handler?

I fear that I should be raising an call in SAPNet (OSS, whatever you want to call it), but hoped that there might be a simple answer out there, but the more I look, the less I believe there is...

Cheers,

Chris

[Former Member · Accepted solution]

Chris,

I read your original question several times, but can't understand events/plug flow.

Neveretheless, the general advice is to avoid mixing events and plugs, specifically do not fire events from plugs.

Here is why:

WD never performs plug navigation directly. Instead, every call to fire plug is saved in some internal queue. So when you are processing action, or firing plug from controller event handler <u>navigation doesn't happen immediately</u>, all calls are queued. At later phase in request processing, WD runtime checks navigation queue and begins to execute requests one by one. Only at this time plug handlers are invoked.

So, try to revisit your code knowing the fact described above

Valery Silaev

SaM Solutions

http://www.sam-solutions.net

[ChrisPaine · Accepted solution]

Hi Valery,

it is a complex situation, and I really didn't hold my hopes very high that anyone would have an answer. However your point below makes sense about the navigation queue (or stack as I referred to it). I think the FPM is doing something to this queue, or that there is a problem in the framework in having a navigation inside a view container, when navigation for the master view is triggered.

Because there is no other way to update the content of a view container than by navigation away from and back to the view it is contained in, I have no alternative but to fire plugs from events. Firing the plug from the event is not the issue, it's that the inbound event is getting cleared from the navigation queue somehow when using the FPM.

I have changed my code to handle and raise the events that I needed to trap from the FPM internally within the single component rather than relying on an FPM event to trap events from other components. This seems to have fixed the issue I'm having. It's less than ideal in so far as flexibility is concerned, but it works and that's the main thing!

Thanks for your help,

Chris

[Former Member]

Hi ,

I am also working on FPM.. and am really curious on this scenario. If you could elobarate this scenario more in relation to FPM or mail me the sample project if any.. it would be of great help.

Regards

Bharathwaj

[ChrisPaine]

Hi Bharathwaj,

The project I'm working on has a requirement to allow for a road-mapped process (FPM) which has one step in which multiple screens can be accessed. I'll give an example: A user in step A selects the cost centre that they want to work with, in step B they need to maintain several pages of information about this cost centre. The do not want to break this information into steps, as there is no logical progression from one step to the next, and it may well be that the user wishes to go from maintaining screen 1 to screen 3, and then screen 2, and then screen 4. Stepping between all screens (1->2->3->2->3->4) wastes time and is not very user friendly. Step C of the process confirms the data that the user entered in step B, and Step D is the validation that the changes have been committed to the database. (a very familar 4 step process for those using ESS).

To allow for this requirement, I have designed a left navigation pane type screen. links appear on the left of the screen and the user can use these to navigate between different screens (implemented as FPM IVAC VCs) on the right of the screen.

It is quite an elegant solution (even if I do say so myself although quite complex to implement. I have relied very heavily on reading the code SAP put together for the FPM. The most complex part is that in order to update the the content of view containers in an application you must trigger a web dynpro view navigation by firing a plug to a different view.

Unfortunately I don't have any sample application code, only the finished product, which I can't really share. But I can say that if you look at the FPM code carefully, working from where the wdInit of the FPM is called, it will eventually make sense.

One thing I found slightly frustrating, you can't use the FPM's component usage register (FPM method attachComponentUsage(IWDComponent, IWDComponentUsage)) to add a VC... darned inconvienient really (you'd think that the web dynpro framework could have implemented the concept of extending an interface, but the IBLC and IVAC interfaces are different! - even though the IVAC is just IBLC + a few methods), but then again you can manage the instantiation of the used VC yourself and call the onInit method of the VC passing the current fpm reference, to attach it to a common FC, and given that you should be sharing context through the FC and never the VC, then really this isn't too much of an issue. (I spent ages worrying that I couldn't add the instances of the VC that I was using within my navigation pane VC to the fpm instance list, until I realised that it really didn't matter!)

One day - when I have time (yeah right!) I might put together a blog about this sort of stuff, in the meantime, it keeps me plenty busy enough not to have the time!

Hope this helped in some small way,

Cheers,

Chris

[ChrisPaine]

Some further refinement...

I thought perhaps it was the event that was causing the issue, so I changed the onActionLink to call a method in the component controller, which raised the event, which fired the plug, which DID call the corresponding inbound event handler!

So it seems that my issue occurs when the event is triggered by something external to the view.

It may be that because the event which does not call the inbound plug event handler is raise from an action in a different window, that I have the problem.

However, my thoughts are still the same - EVERY call to the outbound plug should then execute the corresponding inbound plug event handler. This is not the case here - what am I missing?

Cheers,

Chris