Communication between WDA and ABAP Stack

[alejiandro_sensejl]

Hello everyone,

we are trying to integrate an (existing) WebDynpro ABAP application in one of our (existing) ABAP applications. With ABAP application I mean a huge monitoring tool that uses several ALV grids and trees. As things are now we don't want to migrate that application into a WebDynpro . We aim to add another docking or dialogbox container to that application and start our WebDynpro within that container. Up to this we already got it working!

Now we want to double click in an ALV grid and send the selected line to the WebDynpro application (e.g. to display detail data or generate business graphics). For this purpose we wanted to use static attributes of a class or a function group to exchange the data. The problem is now as far as i understand that there are to separated LUWs responsible for each WebDynpro and our calling application on the ABAP stack. For this call we tested class CL_GUI_WDR_VIEWER and also the function module WDY_EXECUTE_IN_PLACE (which especially has a parameter INTERNALMODE, that triggers some mysterious C-Calls for SSO!), but unfortunately both approaches doesn't seem to work.

Can anyone imagine a way to beat the "WebDynpro sandbox"? Would be great if some gurus could have a look at this!

Thanks in advance and best regards,

Alej

[thomas_jung · Accepted solution]

The scenario you describe of integrating Web Dynpro ABAP inside of classic dynpro screens and having data and event communication is no longer supported by SAP. See OSS note 989286 and 1388292. We do provide functionality to allow you to launch the WDA into a separate browser window from the SAPGUI with SSO. There used to also be some APIs that allowed communication with a WDA running within the HTML control of the SAPGUI via JavaScript. This functionality has since been discontinued and removed or obsoleted from the system - see notes 1148323, 1391460, and 1098009.

>The problem is now as far as i understand that there are to separated LUWs responsible for each WebDynpro and our calling application on the ABAP stack.

Yes this is the case. The WDA will always be a separate user session from the surrounding Classic Dynpro user session. In addition becuase of the possibility of load ballancing the two user sessions may not even be on the same application server. This makes cross session communication on the server extremely difficult.

[alejiandro_sensejl · Accepted solution]

Hello Thomas,

thanks for your very quick response. Does this mean we should scrap that integration completely, because SAP doesn't want customers to integrate WebDynpro into the SAPGUI and even if we find a loophole it is very likely that in a future release this is also closed by SAP? If yes, could you please provide some insight why?

In note 989286 "cross-session techniques" are mentioned. In a first research I couldn't find any further references what this means. Do you know what these are?

Best regards,

Alej

[thomas_jung · Accepted solution]

>If yes, could you please provide some insight why?

We originally had APIs ourselves (as mentioned above) and ran into technical problems with various applications. The multiple user sessions is just one of the main problems, but there were also technical problems when rendering inside the HTML control and communication problems with the JavaScript based eventing in and out of the HTML control. SAP is basically saying even if you find a loophole - we won't support it nor would we recommend it.

>In note 989286 "cross-session techniques" are mentioned. In a first research I couldn't find any further references what this means. Do you know what these are?

The are basically pointing out the main problem of communication if the WDA and SAPGUI sessions are in different sessions. This becomes even more difficult in the situation I described where you have multiple application servers. It is technically possible to do this cross session communcation. SAP does it in 7.02 for the WDA notification service. It requires having a shared memory object and replicating that object across all application servers using RFC. It is one thing to build this complex infrastructure for a reusable framework like the notification service, but I'm not sure the effort would be worth it for application level communication. Plus this was just one of several problems that we faced with this type of communication.

[alejiandro_sensejl · Accepted solution]

Hello again,

thanks for your detailed explanation. Although our system landscape isn't that complex we will now try to get some budget from the higher-ups to port our tool to WDA (the information you provided will help here a lot!). I'm not sure if this will be much fun tough because the core was developed in a 4.6c release and some parts are rather "old school" ;-).

Best regards,

Alej