Storage Question for BSP to Dynpro ABAP

[Former Member]

Hello,<br />

I was hoping to get some opinions on a project that my department is thinking about implementing and I have been tasked with creating. I am relatively new to Dynpro and have been learning as rapidly as I can, so I will describe the basic situation.

<br /><br />

The basic gist is the creation of a password reset system using Dynpro for end-users, as we get around 300~ cases a month for a password reset. This is a fair size of cases to sort through that only require a few minutes of work to perform.

<br /><br />

In this light, my basic idea in solving this through Dynpro involves calling an app up and having a BSP run briefly to grab the user's Windows login (as it is used for their SAP username). The storage from the BSP page to the Dynpro page is where I'd like some opinions. I plan on having a Z table to store the user name for a short few moments as Dynpro fires up and removes it from the "buffer" table to use for processing what systems the user would like to reset on. I do not want to transfer the username via URL as this could pose a possible security risk and allow others to 'spoof' which could lead to malicious use. I was wondering if there perhaps was any other way to do this other than a Z table.

<br /><br />

The reason I ask if there is an alternative to the Z table is due to my concern over the small possibility that two users may access this at identical times and u201Cfudgeu201D the buffer (This however would be highly unlikely as while the resets are common enough, they are rather spaced out).

<br /><br />

Do keep in mind that the Z table itself is not necessarily a bad solution as we have multiple boxes and this one is running Netweaver 7.0 (with no plans to upgrade/change this box anytime soon as well as having a very small user base). This box is not a production box, so it is infrequently used for any processing and editing a table like this would not significantly affect runtime on anything. We also are not currently running any other Netweaver objects such as BSP or Dynpro pages on this box, making this our first one. I mainly was hoping to get a feel if there are other methods of storing this username or if there is a general agreement with my method of thought on using the temporary table buffer to transfer between BSP and Dynpro.

<br /><br />

As a side note, the only reason I need the BSP page is due to Dynpro not having access to GUI commands to get the Windows login. I have also looked for posts dealing with anything relating to this, but it seems to be unusual/unique enough that the few posts I found that had something similiar were specific enough to not work for my project.

[ChrisPaine · Accepted solution]

Hi Patrick,

you might want to consider Shared memory objects - transaction SHMA - and plenty of examples out there - in order to transfer the data, you could create a GUID which you could pass as a parameter to the BSP and then use within the BSP to write to the shared memory area - using the GUID as key. You could then use this GUID to retrieve the memory area and the related data.

This method of transferring info is often used to move large amounts of/sensitive data between sessions - eg used in POWL for passing data to popup windows (new applications running in different memory space)

Hope this helps,

Cheers,

Chris

[ChrisPaine · Accepted solution]

Check out Thomas' blogs:

[Netweaver for the Holidays: A Lession in Sharing (ABAP Shared Memory)|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/1070] [original link is broken] [original link is broken] [original link is broken];

[ABAP Persistent Classes: Coding without SQL|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/1013] [original link is broken] [original link is broken] [original link is broken];

There are probably other references out there, and there are plenty of example in the standard system, but I like Thomas' style

Thomas' blogs are a bit old - and if he reads this thread he'll probably be able to point to a newer version

otherwise, check out package SHARED_OBJECTS

Good luck,

Chris

[thomas_jung · Accepted solution]

These blogs are old, but not a whole lot has changed in Shared Memory objects over the years. The basic techniques are the same even as SAP has added more exceptions for better control.

Keep in mind that Shared Memory objects are per application server. If you have multiple application servers you either need to try something else or build in logic to check/populate Share Memory on each application server.

On alternative might be to use Server Cookies. This is basically just writing the data into a database table - although one SAP provides instead of a Z-Table. There are some utilities for read/write and for cleanup.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/2a/31b97b35a111d5992100508b6b8b11/frameset.htm

[Former Member · Accepted solution]

Thank you Thomas, from the sound of it server cookies are precisely what I was needing. A temporary storage buffer with unique label, just to hold the windows login. You two have been most helpful, and even if I do not use shared memory objects I will keep those in mind for future projects.

[Former Member]

Thank you for those replies. I am going to go ahead and declare the question solved, but please feel free to post more suggestions or any comments you may have if you wish.