I have found many including myself struggling with debugging an Adobe form . I have found some easy ways on how you could do that . I have also separated for 2 cases one where the Print button is in the portal and when you open the document it triggers the code again which is easier to debug. However in some cases the document gets generated in background and makes it a difficult task to be able to debug.
Please read more below:
1. Go to the adobe form interface in transaction SFP and enter the adobe form name.
In the interface section you would see that the details for the program would be maintained . Please click on the interface object and it will navigate you to the interface.
2. Put the debug point for the user in the initialization and Code initialization section this will trigger the breakpoint everytime the adobe form is printed with that specific user ID
However if the document is printed in the background it would NOT trigger this as the user could be a batch user or a WF user which is why the user specific breakpoing does not get triggered.
3. Please note the above way is only useful when you click on print from the portal it will come up and trigger the code using the same ID with which the external or hard coded breakpoints were put as can be seen below for a PO when the print preview is clicked it would be stopped as the system actually captures User 1 doing the task
4. For most of the documents you would see that the documents have been generated in the backend . These documents may also be seen as 'Own spool request' which is also accessible from Tcode SP02. Now if the user clicks on the already generated PDF from here it would not be helpful as this would not be going back to the code hence is just a local copy of the PDF and is not created by the specific user but created using a batch or workflow user in background and they are not a dialog user so external or hard coded debug points do not work in such cases.
Also there may be a case where the code is not actually written in Adobe form but just comes as an input to adobe form from the runtime generated FM . So the steps below would help you to find out how the correct debug point can be found and triggered.
5. To be able to regenerate the PDF so that it calls the code again you need to check via Tcode CORRHIST which is used for seeing the documents printed in the system specifically for the FI module
Select the ICON as highlighted in yellow which is a print with changed parameters options
And then you should select the Reprint option. This retriggered the entire code again of your user Id.
Here it will also first stop on your user specific break point at seen below which was hard coded in Adobe interface section
Once this gets triggered now search for the relevant function modules which gets triggered before that by going through the entire stack and put a session breakpoint which will now directly trigger the code which actually generates the form.
Also another way to find the technical details of the form is;
Using Tcode EFRM. This gives you all details in one place the attributes , interface , generate function module etc. Most of the information provided in here is that provided in the Transaction SFP but all in one place and makes it much more easier to locate.
One of the feature I use mostly in here is of the form class which you can see the below screen. To be able to check the code inside click on coding display.
This should hopefully allow you to debug the forms. Please let me know if you have a better way of doing it and I will include that in the post as well
Thanks for taking time to read .
Regards
Vinita
Please read more below:
1. Go to the adobe form interface in transaction SFP and enter the adobe form name.
In the interface section you would see that the details for the program would be maintained . Please click on the interface object and it will navigate you to the interface.
2. Put the debug point for the user in the initialization and Code initialization section this will trigger the breakpoint everytime the adobe form is printed with that specific user ID
However if the document is printed in the background it would NOT trigger this as the user could be a batch user or a WF user which is why the user specific breakpoing does not get triggered.
3. Please note the above way is only useful when you click on print from the portal it will come up and trigger the code using the same ID with which the external or hard coded breakpoints were put as can be seen below for a PO when the print preview is clicked it would be stopped as the system actually captures User 1 doing the task
4. For most of the documents you would see that the documents have been generated in the backend . These documents may also be seen as 'Own spool request' which is also accessible from Tcode SP02. Now if the user clicks on the already generated PDF from here it would not be helpful as this would not be going back to the code hence is just a local copy of the PDF and is not created by the specific user but created using a batch or workflow user in background and they are not a dialog user so external or hard coded debug points do not work in such cases.
Also there may be a case where the code is not actually written in Adobe form but just comes as an input to adobe form from the runtime generated FM . So the steps below would help you to find out how the correct debug point can be found and triggered.
5. To be able to regenerate the PDF so that it calls the code again you need to check via Tcode CORRHIST which is used for seeing the documents printed in the system specifically for the FI module
Select the ICON as highlighted in yellow which is a print with changed parameters options
And then you should select the Reprint option. This retriggered the entire code again of your user Id.
Here it will also first stop on your user specific break point at seen below which was hard coded in Adobe interface section
Once this gets triggered now search for the relevant function modules which gets triggered before that by going through the entire stack and put a session breakpoint which will now directly trigger the code which actually generates the form.
Also another way to find the technical details of the form is;
Using Tcode EFRM. This gives you all details in one place the attributes , interface , generate function module etc. Most of the information provided in here is that provided in the Transaction SFP but all in one place and makes it much more easier to locate.
One of the feature I use mostly in here is of the form class which you can see the below screen. To be able to check the code inside click on coding display.
This should hopefully allow you to debug the forms. Please let me know if you have a better way of doing it and I will include that in the post as well
Thanks for taking time to read .
Regards
Vinita
- SAP Managed Tags:
4 Comments
