HCM Processes & Forms - Moving from Adobe to WD ABAP - Part 2.

[Former Member]

As I have outlined in the overall plan in my previous blog, I will attempt to explain the approach in this blog. Apart from perfomance the other benefit of using WDA over Adobe would be

1. You can save on the licensing cost of live cycle designer if customer is  good with look and feel of WDA screens.

2. Using ADLC needs some amount of familiarity with the tool and scripting languages like Javascript or formcalc so that is another pain point.

So even if you do not have ADS or ADLC installed you can still leverage the functionality of HCM processes and forms :cool: .

So to raise the curtain, start off with creating the simple switch maintenance table to activate or deactivate the WDA form.

Maintain the flag for the form which needs to appear in WDA format, uncheck if it needs to reappear in Adobe format.

Now the second step should be to develop your Web dynpro application which will mimic your form. Every form is a different web dynpro application but then it has to be called in the main application dynamically, so you will definitely need an WD component interface which can refer to these applications at runtime.

Build the WD Component Interface with the methods shown in the screen shot.

1. Get_Data method will help you in passing the data entered by the user out of the WD component(parameters : fieldname, index, and value).

2. Get_Elements - This will be need to get the elements of a node in case tables are used in the form

3. Set_Data - This will tap the data from ISR and pass the data to WDA for display( parameters : fieldname, index, and value )

4. Set_Mode - This will be necessary to set the read/write mode of WDA based on the scenario stage or review stage.

There should be a single window which will act as the interface view, here I have the created an interface view W_WDA_FORM.

These are the only methods which will be required to handle the calls between the ISR and any web dynpro form application.

After you are done with creating the web dynpro component interface, start creating your web dynpro application which will mimic your adobe form.

The first step would be to incorporate the component controller interface as the implemented interfaces.

Once you have done that, the interface methods will get reflected in the component controller methods.

Now create the component interface node in the same manner as the Adobe Form interface or the field names in your HRASR_DT configuration, the names should exactly match to make things easier. This might be a tedious job to do and may consume a lot of time.

Note that all the context nodes will have only one field, the name of it is always FIELD and is usually of type STRING.

Create the view context similar to the Component controller context and do the corresponding field mapping.

Have some key fields that will be requried in the application as attributes of component controller.

The next step would be to construct the view. The design is left to you, I just followed the tabbed approach to segregate this for a logical grouping.

Some screen shots of WD form.

Once you are done with the screen design, we can go about with implementation of the interface methods and application specific methods for internal event handling.

One very important thing to note here is that whatever event you do on the web dynpro application will not do an ISR round trip, so the logic you have written in the generic services might need to be replicated here. And also, another point to remember is, incase of complex UI elements like tables we should make sure that all the data is captured and pushed to the ISR and also back from ISR to the form, there is a trick here which I will cover later.

These are some local view methods I implemented based on functionality, I am not getting into the details of it.

Coming back to the component controller methods,

the set_data methods is the one which will supply data from ISR to web dynpo, the method should have a simple logic to create a node element if it doesnot exist or update a node element if it exists, indexing will be important for nodes having multiple elements like for the table UI.

The Get_data method should have logic to get the required node value based on name and index, this will supply data to ISR.

The set_iniital_values method is to populate the data from ISR fields in to the tables for display, the tables will have as many rows as the highest index of the field.

The get_elements will be required to get all the elements of a table and hand it over in the ISR event call.

In the next part I will explain how this WDA will be integrated into the ISR framework. Which are the methods that we need to enhance in QISR_UI component for seamless flow of data.

Thanks for reading and be tuned.