Adding fields in Travel WDA Applications

This document shows a practical approach for adding fields in the WDA standard applications FITE_REQUEST and FITE_EXPENSES including the respective business logic and impact on other parts of the FI-TV module. What follows has been done on a system from NW 7.01 / ECC 6.04 to NW 7.03 (731) ECC 6.06; I won’t rule out that the approach is going to work on any system that holds the corresponding sources for the WDYN Components, but.. you never know 😛

In the recent past, I’ve seen quite a lot threads on the travel management subforums that deal with problems like “Where can I add field XYZ…” or “How can I include Information ZZZ..” whereas the ‘end of the story’ of these threads pretty much always seems to be violating standard fields for something they’re not meant for with (most of the time) unknown consequences what impact on the entire FI-TV process might occur. Thus I thought, I’d share my approach (which I partially already shared in numerous discussions) with you as a whole in my very first document 😉 .

Please note:

You should have the following expertise, if you want to fully understand the entire document from a technical side(Info material at the end of document):

• ABAP Dictionary, ABAP/4 + OO in general, Dynpros
• basic knowledge in the development in WebDynpro ABAP
• basic knowledge in Enhancement Framework

My approach contains a solution for Travel Requests and Expenses, but NOT for Planning, i.e. not for FI-TV-PL, since the planning component uses a different data foundation. This document is NOT a step-by-step guide, I will not go into every detail of enhancements, modifications etc.

1. Use Case

“Hey! Programming-Guy! Make it work so that we can use the Standard Web-Thingies for Travel, but we need about 50 dedicated extra fields that have to reflect upon the backend too; also our business process is completely different than assumed in the standard and we need it by FIVE PM! GO! GO! GO!”

Nah. Kidding. But jesting aside, in my company we had the following requirements:

We had to migrate from our current Travel Solution to the one SAP provides without losing any information-depth, without hurting our Public Sector specific travel law (which is quite some son of a gun) and without diverting from our original business process. Having these requirements, our options came down to:

1. Building our own WDYN-Applications (which was no option anymore, though, after considering the TCO)
2. Twist and bend the standard fields to our needs without knowing the entire depth of consequences (and probably bite the hand that feeds you without knowing –> baaaad idea)
3. ‘Somehow’ enhance the Standard organically. This ‘somehow’ is further explained in this document 😉

2. What do we need and what is the technical data foundation?

If you take a look at the Travel Management Implementation Guide, in the branch of data acquisition, there is an entry most people probably don’t even bother clicking on, because the description doesn’t really tell you the whole story:

In short, the IMG entry tells you there is a structure called ‘PTK99’ that can be used to add fields through appends and then make them accessible with minor means of (wanted) modifications in the Screen 9999 of Frame Program SAPMP56T. It also tells you this is not supported for SAP EP; fair enough. Now, what’s most interesting isn’t the screen modification for Transactions PR05/TRIP/TP01 etc; it’s the structure PTK99 itself. If you take a look at the cluster PCL1-TE via Transaction PRTE, you will notice a structure called ‘USER’. This structure ‘USER’ is of the type PTK99. See where this goes? 🙂

The structure PTK99 is used in the cluster and more importantly its macros; it’s used in a lot of standard routines, it’s used in the data retrieval FM’s, it’s used in the standard ADOBE Forms Interfaces etc. etc. etc. The fact that SAP provides this dedicated structure for custom developing activities that is used in vast areas of the standard business logic gives you immens power and possibilities. Now imagine you are using a Z-Table for your custom data that has to stay consistent with the cluster and the transparent tables for the header data, i.e. recreate all the save-update-delete-routines in the dozens and dozens of submodules. It won’t make you happy. Chances are good you miss some and the whole process becomes inconsistent. So, bottom line, in my humble opinion, Z-Tables = bad, PTK99 = good.

Even though you can see I’m a fan of PTK99, I’ll try to stay fair and point out some disadvantages you should be aware of:

• PTK99 is not considered in the WDA applications in Standard (but then, neither are Z-Tables 😛 )
• If you modify/enhance PTK99 and you don’t know what you’re doing (like my former self) you will cause your cluster to become inconsistent. I’ve had an interesting discussion with Sally Redmond about it over here http://scn.sap.com/thread/3194702. Furthermore, by now SAP also provided some notes that diminish the risk of inconsistencies, for example #1533696 and #1689972. In case things go wrong nevertheless, SE14 will save you.
• At some parts in the standard business logic, there are gaps of PTK99 being passed from one module to another. I think to have reported all of them to SAP and all gaps that I found and are within support limitations have been plugged by now. Nevertheless, initially it felt to me, like the idea with PTK99 was implemented by SAP bit by bit and then suddenly all responsible developers dropped dead; but nevermind, as I said, I think all of the gaps are closed (but don’t be angry if you DO find another one 😉 )

What I did, bottom line, was adding nearly 80 fields via an Enhancement Append to the Structure PTK99. So far so good.

3. Backend modifications for data visibility and access

Since it most probably makes sense for most business processes to be able to see and have access to the data that is entered/changed in the WDA Frontend in the Backend as well, there are some minor things that need to be done:

Please Note: The part that follows is identical with the IMG-Documentation of the entry I mentioned earlier; I’ll put it down anyway, in case somebody is too lazy to read it from the IMG 😛

Assuming, you have now enhanced the structure PTK99 with your custom fields, go to SE80 and open the sources for the report SAPMP56T. The report already contains the standard global data variables ‘USER’ for from-database/to-database and ‘PTK99’ for from-screen/to-screen. What you have to do here is modify (since the enhancement framework is not integrated for dynpros) the modules “d9999i_init” and “d9999o_init”, so basically code the shifting of data from USER to PTK99 and the other way around plus the handling of the OK-Codes; but aside from that, you don’t need to do anything since the standard does the rest.

Next, modify the layout of the screen 9999 accordingly to your datafields. Last but not least, go to TA FITVFELD and enable the screen ‘Userdata’ for each trip provision variant and each schema you want.

I really didn’t do more here than the data shifting in the PBO/PAI modules and implement some particular OK codes. The screen painter took me most time I think. Though, it all was done in a couple of hours (not much if you consider the magnitude in the entire business process). Here’s a portion of how it can look like:

4. Frontend Enhancements and integration into the standard business logic

Now that the data foundation is set up, you can go ahead and start enhancing the standard webdynpro components that are part of the Travel Request/Expense Sheet Applications. The most important ones are: FITE_VC_GENERAL_DATA, FITE_VC_ITINERARY, FITE_VC_SERVICE_REQUEST, FITV_VC_COST_ASSIGNMENT, FITE_VC_REVIEW, FITE_VC_RECEIPTS and FITE_VC_CONFIRMATION. I will not go into details what I did here since it’s not the purpose of this document to tell stories about WDA-Development and the Enhancement Framework.

In Short, what I did was:

• enhanced the context and the layout according to my needs for my fields of PTK99
• implemented some custom UI-Fieldcontrol for my PTK99-Fields
• dynamically registered events to standard fields to cause events influencing custom fields and vice versa and did quite some post and overwrite exits (avoid to use overwrite exits if possible, by the way)
• used and enhanced the assistance class CL_FITE_ASSISTANCE for custom business logic access and for data consistentcy in runtime between the different WebDynpro Components

Assuming you now have your custom fields and routines implemented in the WDA environment, the actual interesting question is “how does this correspond with the database and frame program routines”? The Standard WDAs do not support the structure PTK99, however the business logic in SAPMP56T does. Here’s the deal: slightly before the navigation to the WDA FITE_VC_REVIEW, I export the data from my ptk99-context into the abap-memory (for example, in FITE_REQUEST it’s the Method CHECK_GENERAL_DATA in FITE_VC_GENERAL_DATA). Before I break loose a discussion now, yes, there also are singleton instance classes and yes, there also are shared memory objects, but in my scenario I only need the data for the time while the callstack is active and after that it can be eliminated by the garbage collector, so, abap memory it is.

The next thing that is needed, is the old SMOD-Enhancement FITR0003. This SMOD implements a function module EXIT_SAPMP56T_002 which again is called inside of a user exit that is called every time AFTER the Trip Number has been determined and BEFORE the data is saved/updated to the database. Inside this FM, you can manipulate all data that is provided by the FM’s interface and guess what we also have here? PTK99. So, Import back from memory, shovel it to the FM’s Interface and the data is automatically consideres in the further saving routines for the database/cluster.

Up to this point, there are custom fields in the WDA which hold data that is later saved in the standard cluster and that can be accessed from TA TRIP/PR05 for further processing.

One thing is still missing, and that’s the data retrieval from the cluster for further WDA processings, for example when a travel request is changed or when a travel expense sheet is created based on a prior travel request. For this, I use the first call of the method ON_SHOW in FITE_VC_GENERALDATA and the FM HRTRV_IF_GET_TRIP. I had to code an additional enhancement in HRTRV_IF_GET_TRIP for it to successfully pass PTK99 from the local coding to its interface (sending it to the SAP Support was no option here because the FM is not released for customers, i.e. = no support for this). The FM then provides the data for PTK99 from the data base and all that needs to be done after that is post PTK99 back to the custom context of the WDA. All Done.

5. Personal experience after implementation and conclusion

We are running FI-TV with this solution now for about one year and I haven’t been able to blow up the PCL1 cluster yet, despite adding further fields successively(no situation where we had to use SE14). Concerning updates and upgrades it’s also all going very smoothly, SPAU_ENH works great for all enhancement-conflicts, especially in the WDA environment. What I did in addition was connect the package with all my enhancements to a reversible switch that can be switched on and off in the switch framework. This possibility also makes it easy to isolate problems after upgrades (particulary when something crashes and the first thing you would like to know is, whether it’s your own fault for messing with the standard or the fault of the standard itself).

Links to Information sources that can help understanding this document better:

Aight’, I hope this approach is interesting and useful for someone else than myself. I’d be glad to see some destructive criticism etc. concerning this document, so I can get a grip what I can do better next time, for example whether more pictures would be nice or whether I need to explain certain things more clearly/more in detail or whether I should just shut the hell up 😉

Best Regards and Cheers,

Lukas

P.S.  @Laure Cetin; There! Your new gamification interface finally made me blog/write a document! I hope you’re happy now! 😈 😀 😀 😀 :