How to fill Global Internal tables of a "Z" transaction from a web dynpro

[Former Member]

Hi Team,

I have a scenario where I have to call a custom transaction (which is linked to a report - Type 1 Executable - Not a module pool) from one of the methods in my web dynpro view. I tried this and it is possible to do a call transaction. The problem is that I have to fill some global internal tables in the transaction when I make the call. I cannot use Function modules and "Perform IN Program" here because we specifically need to run the transaction. Any thoughts around how to pass data to the transaction (specifically Internal Tables)?

Some things which come to my mind, but are not successful:

1) Use of Common parts

2) Use of LOAD-OF-PROGRAM

3) Shared memory is ruled out because there will be many users which will use the WD transaction at the same time and we won't have enough memory for sharing.

I was not able to successfully implement these but might be doing something incorrectly.

Any help and pointers would be appreciated.

Thank you for your time.

Regards

Sanjay

[Former Member · Accepted solution]

Thank you Tom,

I'll elaborate on the actual process to bring more clarity. We are using the BAPI_PO_CREATE1 function in the Web Dynpro. The change documents generated out of this BAPI actually does not have any transaction code populated in CDHDR because the BAPI is called from the Web Dynpro. We have downstream BI reports which read this Transaction code and filter out some specific records based on the business rules. The idea was to somehow fill the Tcode in CDHDR for PO's created by the Web Dynpro.

I tried the following line of code before the BAPI call in the method of the WD view : "sy-tcode = 'ZWEB_ORDER'" and it works fine, but as per recommendations from the SAP COE, it is not advisable to change the system variables because they can easily get a new value in the BAPI.

To circumvent this problem, I created a custom transaction attached to a simple report (executable Type 1) and moved the BAPI call in this report. The challange was to pass the BAPI data to this report from the WD application. I'm using a call transaction to run the BAPI from WD.

To give more context, we have replaced a standard ITS IAC with this custom WD application. The standard application always has the sy-tcode populated because the ITS IAC transaction is called behind the scenes. This ITS transaction also calls the BAPI, and the Tcode is filled properly in CDHDR. Standard SAP Support only suggested in one of our customer messages to use this Tcode as a filter in the custom BI extractor.

Hope this explains the scenario. I'll try the Server Cookie and update this message.

Thanks again for your time Tom. SDN is an excellent innovation for bringing the community together and do some brainstorming.

Regards

Sanjay

[thomas_jung · Accepted solution]

>Standard SAP Support only suggested in one of our customer messages to use this Tcode as a filter in the custom BI extractor.

How long ago was that? I have to say that the root cause of this very complicated situation seems to be a bad design of building anything around the Tcode. In today's SAP world of Web Dynpro and Enterprise Services I would totally avoid anything Tcode related. It simply has no meaning in the way applications will work in the future.

[Former Member]

Yes, you are absolutely correct. I'll talk with business to relook at the design itself and if we can come up with business rules to avoid the Tcode based filter in the BI extractor. That way, we are in line with the new direction of SAP.

This was done in early 2006 and is totally related to custom extractors (Nothing Standard). Our project was SAP primed and though this was pushed to SAP consulting and CDP, the client insisted that a scenario specific note be given (or else they won't go live, a very high priority escalation - This was one of the classic stalemate situations with the clients). We finally got an informal suggestion from one of our colleagues from SAP and in no way this was formalized in any note or a standard recommendation.

Thank you Tom for giving a clear cut direction on this issue. I'll close this thread as I know the correct answer now.

Regards

Sanjay

[thomas_jung]

I'm not sure I'm exactly clear on what you are trying to do, but assuming you can alter the called transaction to read the data - you can pass all kinds of objects via the EXPORT TO command. If you want to totally avoid the usage of memory (even just session memory) then you can always just temporarily write the data into the database. For instance with a server cookie or by altering your EXPORT TO to use DATABASE instead of MEMORY ID or SHARED MEMORY.