In the Central Finance projects one of the challenging aspect is to analyzing AIF messages through debugging. Due to the complexity of the solution and tight integration between AIF and Central Finance interface its very easy to get confused and to find the correct method for debugging the AIF messages.
In this guide I would like to provide methods which I have used during my support to multiple Central Finance customers during my tenure. This blog post aims to provide clarity on different debugging techniques as well as consequences and outcomes of each method which will be beneficial for anyone who is starting their Central Finance journey and also to seasoned Central Finance consultant.
The post is divided into two sections naming the easy way and the hard way. As you can guess from the naming the easy way provides the less complex approach while the hard way could be more challenging and only used in exceptional circumstances with extreme caution. Nevertheless all these methods are tested and should provide solutions on debugging approach based on your requirement.
In this section we will go through some of the common techniques used for debugging which are used to debug unsuccessful AIF messages i.e. messages that are in error or in process in AIF.
Approach 1: Analyze/Debug ‘In Error’ AIF messages using /AIF/CL_APPL_ENGINE_XML class
To debug AIF messages stuck with application or technical error this is the easiest method to follow. The one drawback of this approach is to have goto statement authorization in the system which might be unlikely or harder to get in live productive environment.
Set break-point in following class/method on line 55.
Class: /AIF/CL_APPL_ENGINE_XML
Method: /AIF/IF_APPLICATION_ENGINE~RESTART
Select Document & Restart via transaction ‘/AIF/ERR’ (AIF Monitoring and Error Handling)
In debugger, stop at line 55 and jump to line 63 using goto statement(use Shift+F12 for shortcut).
Once you reach this line, based on the error message in the AIF log you can set a breakpoint on that particular message class and number and backtrack in the call stack to identify the root cause. For example my example GUID had an custom error message generating from Central Finance BADI so I put a breakpoint on that specific message. After that click on Continue by selecting from toolbar Debugger>Continue or press F8. AIF processing will occur in the foreground, step through code / navigate to location of the error message to analyse.
Approach 2: Analyze/Debug ‘In Error’ AIF messages using function module /AIF/RESTART_MSG
In many cases as above mentioned before we might need to debug the AIF message in a system where goto statement authorization is not provided. In likely cases of live productive environment the following approach can be taken.
In SE37 execute function module /AIF/RESTART_MSG
Use the following parameter of the function module
After filling the details click on execute via debugging(Ctrl+F7 shortcut) button.
At this point you would be in the AIF processing mode inside your debugger and as mentioned before in the approach 1 set break point based on error message and press continue or F8 to reach the error message and analyse the error.
Important Hint: Sometimes using this method the error GUID will go into In Process state if the debugger session is abruptly terminated or lost connection. But not to worry if that happens just go back to /AIF/ERR transaction and restart the GUID and get back to error state before analyzing the GUID using the same approach.
Approach 3: Analyze/Debug ‘In Error’ using program FINS_CFIN_AIF_ANALYZER
As the name suggest SAP has inbuilt tool to analyze AIF error message. This tools gives you flexibility to analyse as well see associated staging data that was passed to Central Finance from source system. Based on your release this tool might be there in your system or need to implement SAP Note 3294277.
Disclaimer: Please note this tool is strictly for analysis purpose and any bugs or issues on the program cannot be reported to SAP so please use this with caution and as per your discretion.
Use the error GUID from AIF/ERR in the selection screen and press execute.
After this you will be presented with the below screen. In the screen on the toolbar you can see the button shown as inactive which shows the current debugging status.
Click on the inactive and the status of the debugging changes to active and then click on simulate to goto into debugger. The program will go into AIF processing mode and from here you can set breakpoints on message, classes or function modules based on your error message as mentioned in approach 1 & 2 to navigate to the desired place analyse further.
Approach 4: Analyze/Debug ‘In Error’ by generating IFTEST file
This method of debugging has already been discussed by our fellow blogger in this blog post. Kindly go though it for detailed explanation on the process.
In many cases we might need to debug messages that are already posted in Central Finance. These example might be discrepancy in posted amounts, fields updated incorrectly or many more. In these exceptional circumstances the following method of debugging a GUID which is already posted might be valuable to find the root cause. This method will also require goto statement and change debug access.
Disclaimer: As mentioned before this method should be only used in exceptional circumstances by seasoned consultants/developers, please be aware using this method on live productive system is not advisable. Also if executed incorrectly this will lead to duplicate postings. Use extreme caution and necessary approvals before proceeding with this method.
Set a breakpoint on following class and method and change the value of field lv_assigned from 'S' to 'E'
Class:/AIF/CL_AIF_ACTION_HANDLER
Method:ON_RESTART_1
Line No:75
Set a breakpoint on class: /AIF/CL_APPL_ENGINE_XML and method: /AIF/IF_APPLICATION_ENGINE~RESTART and follow steps of skipping code(from line 55 to 63) as described in Approach 1 using goto statement.
On the same class and method i.e. /AIF/IF_APPLICATION_ENGINE~RESTART goto till line 96 and execute the method call. After the method call change the value of lv_allowed to X.
This will allow the AIF interface to treat the message as not processed and allow the restart of the message.
Open function module /AIF/FILE_PERFORM_ACTIONS in SE37 and set a breakpoint on line 187 where its making a call to function module BAL_GLB_SEARCH_MSG and after the execution of this function module change the value of sy-subrc = 4. (This step might not be required in some cases i.e. if the function call does not reach this point you can ignore it)
We are almost done with the code skips and variable changes at this point and based on AIF point of view, the processing should start and the message will be restarted. So what does mean for root cause analysis then? At this point you should decide on what area of the code you need to evaluate for this successfully posted document. As we don't have error message to rely into like other In error message cases we need to set breakpoints on code where we need to perform the RCA. For example in my case I wanted to check the code behaviour of Central Finance BADI for enhancing the standard processing of posting data so I set a break point inside the BADI and continued till that point.
As you maybe are already aware that the Central Finance interface checks for duplicate documents if we are trying to post the document with same source system data and issues an error message. To overcome this scenario and to dig deeper into the call stack to analyse further, we need to follow the below steps.
Set a breakpoint on class CL_FINS_CFIN_AC_DOC_AGENT method DUPLICATE_ITEMS_EXIST.
When the code reaches at the end of the method change the value of the field rv_duplicates_exist to blank(abap_false).
This will allow Central Finance Inbound Agent for Accounting Interface class to recognize the document as not posted and allow further into the standard code to debug and check further for Root cause analysis.
Note: On of the drawback of this method is, the GUID which is being analysed will go into In Process state and if you reprocess it will go into error with error message document was already posted. If you can get away with the drawback then this method can be used.
In this blog post we discussed different approaches of debugging for root cause analysis for Central Finance leveraging some of the ABAP techniques and by manipulating data. The approaches mentioned for easy way is for novice users where the hard way is for experienced seasoned consultants. In any case this is just a guide only and any approach taken by you should be consulted and checked thoroughly before applying.
I hope you find this post helpful and comment your approaches as well. Till then Happy Debugging !!
In this guide I would like to provide methods which I have used during my support to multiple Central Finance customers during my tenure. This blog post aims to provide clarity on different debugging techniques as well as consequences and outcomes of each method which will be beneficial for anyone who is starting their Central Finance journey and also to seasoned Central Finance consultant.
The post is divided into two sections naming the easy way and the hard way. As you can guess from the naming the easy way provides the less complex approach while the hard way could be more challenging and only used in exceptional circumstances with extreme caution. Nevertheless all these methods are tested and should provide solutions on debugging approach based on your requirement.
Debugging the easy way
In this section we will go through some of the common techniques used for debugging which are used to debug unsuccessful AIF messages i.e. messages that are in error or in process in AIF.
Approach 1: Analyze/Debug ‘In Error’ AIF messages using /AIF/CL_APPL_ENGINE_XML class
To debug AIF messages stuck with application or technical error this is the easiest method to follow. The one drawback of this approach is to have goto statement authorization in the system which might be unlikely or harder to get in live productive environment.
Set break-point in following class/method on line 55.
Class: /AIF/CL_APPL_ENGINE_XML
Method: /AIF/IF_APPLICATION_ENGINE~RESTART
Select Document & Restart via transaction ‘/AIF/ERR’ (AIF Monitoring and Error Handling)
In debugger, stop at line 55 and jump to line 63 using goto statement(use Shift+F12 for shortcut).
Once you reach this line, based on the error message in the AIF log you can set a breakpoint on that particular message class and number and backtrack in the call stack to identify the root cause. For example my example GUID had an custom error message generating from Central Finance BADI so I put a breakpoint on that specific message. After that click on Continue by selecting from toolbar Debugger>Continue or press F8. AIF processing will occur in the foreground, step through code / navigate to location of the error message to analyse.
Approach 2: Analyze/Debug ‘In Error’ AIF messages using function module /AIF/RESTART_MSG
In many cases as above mentioned before we might need to debug the AIF message in a system where goto statement authorization is not provided. In likely cases of live productive environment the following approach can be taken.
In SE37 execute function module /AIF/RESTART_MSG
Use the following parameter of the function module
IV_MSGGUID <YOUR_ERROR_AIF_GUID>
IV_RTCFGR_NS /FINCF
IV_NS /FINCF
IV_IFNAME AC_DOC
IV_IFVERSION 2
After filling the details click on execute via debugging(Ctrl+F7 shortcut) button.
At this point you would be in the AIF processing mode inside your debugger and as mentioned before in the approach 1 set break point based on error message and press continue or F8 to reach the error message and analyse the error.
Important Hint: Sometimes using this method the error GUID will go into In Process state if the debugger session is abruptly terminated or lost connection. But not to worry if that happens just go back to /AIF/ERR transaction and restart the GUID and get back to error state before analyzing the GUID using the same approach.
Approach 3: Analyze/Debug ‘In Error’ using program FINS_CFIN_AIF_ANALYZER
As the name suggest SAP has inbuilt tool to analyze AIF error message. This tools gives you flexibility to analyse as well see associated staging data that was passed to Central Finance from source system. Based on your release this tool might be there in your system or need to implement SAP Note 3294277.
Disclaimer: Please note this tool is strictly for analysis purpose and any bugs or issues on the program cannot be reported to SAP so please use this with caution and as per your discretion.
Use the error GUID from AIF/ERR in the selection screen and press execute.
After this you will be presented with the below screen. In the screen on the toolbar you can see the button shown as inactive which shows the current debugging status.
Click on the inactive and the status of the debugging changes to active and then click on simulate to goto into debugger. The program will go into AIF processing mode and from here you can set breakpoints on message, classes or function modules based on your error message as mentioned in approach 1 & 2 to navigate to the desired place analyse further.
Approach 4: Analyze/Debug ‘In Error’ by generating IFTEST file
This method of debugging has already been discussed by our fellow blogger in this blog post. Kindly go though it for detailed explanation on the process.
Debugging the hard way
In many cases we might need to debug messages that are already posted in Central Finance. These example might be discrepancy in posted amounts, fields updated incorrectly or many more. In these exceptional circumstances the following method of debugging a GUID which is already posted might be valuable to find the root cause. This method will also require goto statement and change debug access.
Disclaimer: As mentioned before this method should be only used in exceptional circumstances by seasoned consultants/developers, please be aware using this method on live productive system is not advisable. Also if executed incorrectly this will lead to duplicate postings. Use extreme caution and necessary approvals before proceeding with this method.
Set a breakpoint on following class and method and change the value of field lv_assigned from 'S' to 'E'
Class:/AIF/CL_AIF_ACTION_HANDLER
Method:ON_RESTART_1
Line No:75
Set a breakpoint on class: /AIF/CL_APPL_ENGINE_XML and method: /AIF/IF_APPLICATION_ENGINE~RESTART and follow steps of skipping code(from line 55 to 63) as described in Approach 1 using goto statement.
On the same class and method i.e. /AIF/IF_APPLICATION_ENGINE~RESTART goto till line 96 and execute the method call. After the method call change the value of lv_allowed to X.
This will allow the AIF interface to treat the message as not processed and allow the restart of the message.
Open function module /AIF/FILE_PERFORM_ACTIONS in SE37 and set a breakpoint on line 187 where its making a call to function module BAL_GLB_SEARCH_MSG and after the execution of this function module change the value of sy-subrc = 4. (This step might not be required in some cases i.e. if the function call does not reach this point you can ignore it)
We are almost done with the code skips and variable changes at this point and based on AIF point of view, the processing should start and the message will be restarted. So what does mean for root cause analysis then? At this point you should decide on what area of the code you need to evaluate for this successfully posted document. As we don't have error message to rely into like other In error message cases we need to set breakpoints on code where we need to perform the RCA. For example in my case I wanted to check the code behaviour of Central Finance BADI for enhancing the standard processing of posting data so I set a break point inside the BADI and continued till that point.
As you maybe are already aware that the Central Finance interface checks for duplicate documents if we are trying to post the document with same source system data and issues an error message. To overcome this scenario and to dig deeper into the call stack to analyse further, we need to follow the below steps.
Set a breakpoint on class CL_FINS_CFIN_AC_DOC_AGENT method DUPLICATE_ITEMS_EXIST.
When the code reaches at the end of the method change the value of the field rv_duplicates_exist to blank(abap_false).
This will allow Central Finance Inbound Agent for Accounting Interface class to recognize the document as not posted and allow further into the standard code to debug and check further for Root cause analysis.
Note: On of the drawback of this method is, the GUID which is being analysed will go into In Process state and if you reprocess it will go into error with error message document was already posted. If you can get away with the drawback then this method can be used.
Conclusion
In this blog post we discussed different approaches of debugging for root cause analysis for Central Finance leveraging some of the ABAP techniques and by manipulating data. The approaches mentioned for easy way is for novice users where the hard way is for experienced seasoned consultants. In any case this is just a guide only and any approach taken by you should be consulted and checked thoroughly before applying.
I hope you find this post helpful and comment your approaches as well. Till then Happy Debugging !!
- SAP Managed Tags:
3 Comments
