Thursday, February 14, 2013

Workflow Debugging with Break-Point

All through out my career in SAP as an ABAP developer, I admit that programming or debugging in SAP Workflow was very rare and seldom that I encountered it in my work. It was then a fortunate time, after 2 years, when one of my projects is using workflow to process its asset posting. I was so lucky then that one of our programmers is an expert in working with workflow which I did not hesitate to take the opportunity to ask so many questions with regards to Workflow especially in debugging. Many of us for sure, especially for first timers, who were assigned to debug a Workflow came across a situation where debugging of workflow was not an easy task or I say at least your break-point was triggered as an attempt to be able to have a peek if what is really happening on the variable that you think is the culprit of your problem! If you are currently looking for the solution, I can say that you landed to the correct page and you are very fortunate since, I was able to perfect and master this debugging dilemma in Workflow environment.

So to start with, there are two types of debugging techniques that I know so far at least in a faster way especially for beginners. These are:

1. Through tcode SWI1 logs and
2. Through background process deactivation

Okay, without any further ado, let's begin with no. 1 - debugging through SWI1:

The first thing that we need to do is to see it that the transaction that needs to be checked includes workflow process, otherwise there will be no logs available in SWI1 for that specific process you are supposed to debug. Okay, so assume that you have a valid workflow process, you may now run tcode SWI1 after running your process or transaction. Below is the screenshot of SWI1 log initial screen:


Then, you may enter the IDentification if you know it, otherwise just proceed if you are just minutes away before landing on SWI1.


So, let us say that you are aware of the item that you are looking for, you should then select it and proceed by clicking the workflow log icon :


Below, depending on your default setting, a workflow log will appear as the below view:


As with my preference, I usually view this on a List with Technical details and this can be found by clicking the second icon on the taskbar.


While on the technical detail screen, you may look for the particular task that you may want to debug. Usually, the last task item appears on the tree is the item where the error occurs. For sure, there are a lot of reasons where the root of your problem may happen within the workflow tasks, but it is likely that the first thing that you may do is through an object debugging. In my example above, let us say we will debug item with the task id TS91000121. So, what we are going to do next is by clicking that task ID with the underline for us to be able to go to its method and to put a break-point as shown on the following screens:


Double click the object type to view the class methods as shown below:


In our example, double click the read_step_occurence to view the ABAP code and you may now look for the line of codes that you may want to put the break-point into.


Okay, I can see now the smile on your face, if not don't worry as we are not yet finished! :)

To start with the actual debugging, let's go back to the workflow log with technical details and look for the request ID generated. This can be found in the container tab and this request id assignment in the workflow container varies from the design of your application:


Once, you have now the necessary parameters, we may now start debugging the workflow class by creating the instance as shown below:


After the instance has been created, you may now run the method of the task and make sure it is where you put your break-point on.


By clicking the above icon, you are then required to enter some parameters to process your debugging correctly.


You may now generate the debugging screen by clicking any one of the clock icons above.

ABS_REQ_EE can be found also in the container together with the REQID.

Then, voila! your break-point is now triggered.



Enjoy and please don't forget to share or like!

Background process: In this case, the break-point should be triggered when running your actual tcode or program and not inside SWI1 unlike the other process above.

1. Put a breakpoint to the method in BOR where being processed by the workflow
2. Double check the particular task where you set the break-point and where the method belongs to.
3. Inside the task, uncheck the background processing
3b. Uncheck the dialog check box when you double click the method in bor
4. Click binding or as long as the agent will become editable. 5. Change the agent fields to User then put your account ID adjacent.
6. Save and Activate the workflow.

Test:

To test, perform your project and after processing it, there should be a workflow item in your inbox - click it and the debugging window should now appear and stop to your break point.

NOTE:

1. If agent field still not editable when unchecking the background check box then you may run swu_obuf to refresh, log-off - log-on or to uncheck and check other checkboxes.

2. Make sure to edit the updated workflow version.

Monday, February 04, 2013

SAP Payment through DMEE

Follow the bellow steps:

1. Create your DMEE mapping in DMEE tcode:

a. Usually payment is done under tree type PAYM and type the name of your format tree then click create:




b. You should provide proper node hierarchy and the basic should look like the one below:





c. For each node, you should provide a level number depending on how the level is printed in the file
d. You should also determine the proper sorting per level:



e. You may also create the segment to group the element (field in the file).
f.  Each element can be mapped in variety of ways as shown in the mapping procedure:




d. Aggregation is usually used in summation

e. Atom is used usually when you want to concatenate nodes.

f. Exit module if there is a special procedure needed before showing the data such as this standard function modules

g. The best exit module that can be used is the "DMEE_EXIT_TEMPLATE_EXTEND_ABA"
    In this module, you may filter the reference node, format tree and other filters you may want to add     based on table FPAYH, FPAYHX, and FPAYP.

h. You may also consider adding a parameter table for each field. In our example below we used country code, country key, reference field, and format tree as parameters:

      SELECT SINGLE SUBR FROM YFIDMESUBR INTO l_wa_subr-subr
      WHERE bland    wa_item-FPAYP-bland       AND
            bukrs    wa_item-FPAYP-bukrs       AND
            tree_id  wa_extension-node-tree_id AND
            ref_name wa_extension-node-ref_name.

SUBR field will contain your subroutine that you may use to filter specific logic inside the function module exit specific for each country, country key, etc.


2. Determine your enhancement in what category in order to locate the appropriate data in tcode FBZP.

EX:

a. Selecting Payment methods by country in FBZP:





b. Create an entry that should be look like this:




c. Enter the appropriate setup based on the requirements and don't forget to fill up the Payment Medium area:





Notes: Put "DMEE" as node reference for reference type element for type 4 and 5.