This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Table of Content 1 Introduction ..................................................................................................................................... 4
1.1 About This Document 4 1.2 Customer Requirements 4 1.3 Staff and Skills Requirements 4
2 Exception Handling During End-of-Day Processing .......................................................................... 6 2.1 Introduction 6 2.2 Exception Handling Overview 6 2.3 General Remark to Errors Within Mass Processing 9 2.4 Errors Within an Application Component 9 2.5 Errors Outside the Initiating Application Component 12 2.6 Errors “in Between” Application Components 14 2.7 Avoid Error Situations by Using Repeat Functionality of the Framework for Parallel Processing 15 2.8 Mass Run Monitoring with Transaction BANK_PP_MONITOR 16 2.9 Repeat of a Mass Run with the External Run ID 18 2.10 Summary 19
3 Return Code Handling ..................................................................................................................... 20 3.1 Introduction 20 3.2 Technical Job Status of a Background Job 20 3.3 Application Return Code 22 3.4 Handling of Job Status and Application Return Codes by an External Job Scheduling Tool 23 3.5 External Job Scheduling Example: Return Code Handling with the Central Process Scheduling by
Redwood for SAP NetWeaver 26 3.6 Simple Test Case to Verify If a Job Scheduling Tool can Handle Both Return Codes 29 3.7 Summary 30
5 Appendix ......................................................................................................................................... 37 5.1 List of End-Of-Day Reports 37 5.2 Additional Information 43
Table of Figures Figure 1: Master Contract Management and Account Management Running on One Instance ............ 8 Figure 2: Master Contract Management and Account Management Running on Different Instances .... 8 Figure 3: Error Within an Application Component .............................................................................. 10 Figure 4: Error Outside the Initiating Application Component ............................................................. 12 Figure 5: Screenshot ECH Customizing ............................................................................................ 13 Figure 6: Error “in Between” Application Components ....................................................................... 14 Figure 7: Setup of Direct and Sequential Repeats ............................................................................. 15 Figure 8: Framework for Parallel Processing - Dynamic Model .......................................................... 16 Figure 9: BANK_PP_MONITOR - Overview of Mass Runs ................................................................ 17 Figure 10: BANK_PP_MONITOR – Packages ................................................................................... 17 Figure 11: BANK_PP_MONITOR – Objects per Package .................................................................. 17 Figure 12: External Run ID of a Mass Run ........................................................................................ 18 Figure 13: SM37 Job Overview ......................................................................................................... 21 Figure 14: Runtime View on Background Jobs .................................................................................. 21 Figure 15: Example of a Job Chain Definition with Redwood ............................................................. 26 Figure 16: Example of a Job Ended with Errors ................................................................................. 27 Figure 17: Final Status Handlers ....................................................................................................... 28 Figure 18: Return Code Mapping to Completed ................................................................................. 28 Figure 19: SLG1 Log ......................................................................................................................... 29 Figure 20: SM37 Job Log .................................................................................................................. 30 Figure 21: Job Status in Redwood..................................................................................................... 30 Figure 22: Locks of Other Application Types Relevant for Application Type ....................................... 35
In addition to the best-practice document, this document will provide more detailed information about exception handling within banking services from SAP. The main goal is to describe the different situations where errors can occur and which transactions (including the necessary setup) can be used for monitoring, analyzing, and follow-up activities.
The aspect of inter-application-component communication is especially taken into account. This aspect is important because—due to decoupling, scalability, and SOA enablement reasons—the kind of communication between application components within banking services from SAP is new compared to Transactional Banking (TRBK) releases.
Furthermore, this document describes some aspects to be considered during the setup and operation of end-of-day processing. So, for instance, it describes what kind of return codes, from a banking services from SAP point of view, are relevant with respect to end-of-day mass runs and how the return codes should be handled.
Last but not least, this document will discuss “Exception Handling” as an important part of a bank’s daily business.
1.2 Customer Requirements
Experiences from customer projects show that missing knowledge about exception handling and system monitoring sometimes leads to many unhandled errors in the system. Unhandled errors may lead to customer complaints (for example, if postings have not been performed) and unsatisfied customers. Depending on the error, it might be even more difficult to fix the longer it exists in the system. Therefore, exception handling and monitoring should be established as an essential part of the implementation project and daily operations. It is also essential that knowledge transfer and handover take place between the project teams, for example, from the implementation team to the operations team and to the user departments. Responsibilities should be clear for the involved parties.
1.3 Staff and Skills Requirements
This document will provide the operations team with an idea of what to do in case of errors and will give the implementation team more information about the system setup. The task of the operations team is to monitor the system (for example, backend system and job scheduling system) and analyze and fix technical errors. The implementation team is responsible for setting up the relevant business processes and tools, including Postprocessing Office (PPO) and Posting Control Office (PCO), to enable the user department to monitor and fix errors.
The end-of-day process is an important task at a bank. End-of-day processing includes activities to close a day. These activities include, for example, settlement of accounts, creation of bank statements, and execution of standing orders. Because many activities are necessary during end-of-day processing, it is important to optimize these activities to perform them within a given time frame. Errors may influence the processing time, so it is important to streamline the error-handling processes. Knowledge about exception handling is therefore absolutely necessary.
Planning end-of-day activities is an important task within the implementation and operation project (more information can be found in the best-practice document SAP Banking Services / Deposit Management – End of Day/ Batch Processing). Exception handling should be part of this planning.
Errors may occur during the execution of the end-of-day processes. There could be runtime errors, for example, due to technical reasons (system or database problems) or software-related reasons, processing errors (for example, exceptional situations that lead to an error for a specific object), or business-process-related exceptions (for example, missing or incorrect configuration of a business process). Depending on the kind of error, there are different measures to handle them. The reaction time depends on the kind of error. System or database problems have to be handled with priority 1; otherwise, end-of-day processing cannot be continued and finished in time. The same is valid for runtime errors. If there is an exceptional situation that leads to an error, successor activities may not be started and the closing of the day may not be possible. Therefore, it is mandatory to monitor end-of-day processing activities.
But there are also other errors that are not that immediately critical and that can be analyzed on the next business day. For example, an account could not be settled because the settlement feature is locked. Usually, these are errors that can only be solved by the user department with special business process knowledge.
2.2 Exception Handling Overview
The most important tool for exception handling is the Postprocessing Office (PPO). Nearly all mass runs that can be used in end-of-day processing within banking services from SAP create PPO orders in case of errors. A postprocessing order contains information (for example, account number, business partner, business process information, error messages) that is helpful to analyze the cause of an error.
There are two kinds of PPO orders: “Classical” orders and the orders created by the Error and Conflict Handler (ECH). Classical PPO orders only contain information about the failed object (for example, account), additional objects (for example, business partner) and the error messages that occurred during processing. Once the error is solved, the relevant report can be restarted to reprocess the object and a user can set the
PPO order to “completed.” This type of PPO order is created, for example, by the account settlement and account statement mass runs.
PPO orders created by the Error and Conflict Handler (ECH) are created for asynchronous messages for which an error occurred during processing. ECH PPO orders include all data provided by the initiating process and, therefore, it is possible to repeat (manually or automatically) this specific process step out of the PPO once the error is analyzed and corrected. An example of a process that creates ECH PPO orders is the posting of payment orders or payment items created by combined settlement.
Asynchronous communication is used, for example, by the Master Contract Management applications Facilities or Combined Settlement, which communicate with accounts located in the Account Management component. Another example is the communication between Account Management and FI-CA for loans processes.
Within banking services from SAP, several application components, for example, Account Management and Master Contract Management, are decoupled from each other. Decoupling the components makes it possible to run them on different instances.
Communication between the application components is either synchronous (for example, immediate response to a query) or asynchronous (either no response is expected or response can be sent at a later time) and can be done using Remote Function Call or enterprise service, for example. In addition to the communication between application components within banking services from SAP, communication to other SAP or non-SAP systems may be necessary, for example, to FI-CA or to a general ledger system, for some processes.
The following diagrams show examples of the communication between different components via RFC channel.
2.3 General Remark to Errors Within Mass Processing
Several error situations can occur during the processing of a mass run. The errors can be categorized as follows:
- Runtime errors (short dumps)
Runtime errors can occur if there are technical problems (for example, database or server problems) or if there was an exception during processing that cannot be handled by the software or software errors (syntax errors). If a runtime error occurs, the program and the related background job are terminated immediately. For a parallelized mass run, this means for example, that one parallel job (main job) is terminated. Other main jobs are not necessarily affected. In case of a general problem, however, all other main jobs will also end with a short dump. A PPO order will not be created when a program ends with a runtime error.
The mass run will end with an application return code = 8. It is recommended that you perform an error analysis by using transaction ST22. In addition, check the job log by using transaction SM37.
- Processing errors
There may be situations where the software is not able to continue processing an object because of an exceptional situation (for example, due to plausibility checks, locking situation, or incorrect or missing configuration). But instead of terminating (runtime error) the program, an error message is raised. As a result, a PPO order is created for the affected object. The error has to be analyzed to decide whether it is a configuration issue (for example, product not set up correctly) or a programming error.
The mass run will end with an application return code = 4.
- Business-process-related errors
Errors can also occur if a business object, for example, an account contract, violates certain business rules, for example, account is locked via Posting Lock Management and therefore a settlement cannot be executed. Business rules in the form of posting control rules are also used by item management, for example, limit check.
Note: Errors as a result of a posting control rule violation will end up in the Posting Control Office (PCO) and not in the Postprocessing Office.
The mass run will end with an application return code = 4.
2.4 Errors Within an Application Component
Nearly all mass runs in banking services from SAP create PPO orders in the case of errors. When an object cannot be processed, for example due to business rules, a PPO order is created with relevant information to analyze the error. The created PPO order is a “classical” order and is assigned to the application component in which the error occurred.
All error messages created by a mass run are also written to a log. You can display the mass run log either with a specific application transaction or with transaction SLG1. It is recommended that you use the specific application transactions to display the log, because they may use a special logic, for example, with regard to sorting.
Sorting of the SLG1 log may not be equal to the sorting when you use the specific application
transaction.
Within banking services from SAP, the following transactions are available to edit or display PPO orders:
- PPO orders for application component Account Management (FS-AM)
o BCA_PPO2 - Edit Postprocessing Order o BCA_PPO3 - Display Postprocessing Order
- PPO orders for application component Master Contract Management (FS-MCM)
o MCM_PPO2 - Edit Postprocessing Order o MCM_PPO3 - Display Postprocessing Order
- PPO orders for Posting Lock Management1
o PLM_PPO2 - Edit Postprocessing Order o PLM_PPO3 - Display Postprocessing Order
- General PPO transaction (application-component independent)
o /n/SAPPO/PPO2 - Edit Postprocessing Order o /n/SAPPO/PPO3 - Display Postprocessing Order
PPO Setup
By default, the creation of “classical” PPO orders is deactivated. You have to activate the creation in IMG by choosing Cross-Application Components General Application Functions Postprocessing Office Postprocessing Office Business Processes Activate Creation of Postprocessing Orders. 1 Currently, PPO orders assigned to FS-PLM are only created by the effective cash pooling process via ECH.
It is recommended to activate PPO for the following components: - FS-AM - FS-MCM - PRI (Pricing: Use transaction /n/SAPPO/PPO2 to work on Pricing PPO orders. There is no
specific transaction for Pricing.)
To activate PPO for all business processes of a component, leave the business process blank. At minimum, the following entries should exist in the table:
Component Business Process Act. FS-AM X FS-MCM X PRI X
You can also find the relevant PPO activities in the IMG path of the application component: Financial Services Account Management or Master Contract Management Postprocessing Office Business Processes Activate Creation of Postprocessing Orders. You should also consider if it makes sense to use worklists for PPO orders. With worklists, you are able to assign responsibilities for specific business processes to specific users. For example, if there are specific users who should take care of item-specific errors, these users can be assigned to an item worklist. Other users may take care of settlement-specific errors. These users can be assigned to a settlement worklist. The IMG path to define worklists is Financial Services Account Management or Master Contract Management Postprocessing Office Worklist. Once a worklist has been created, the PPO business processes can be assigned to it. Afterward, you can assign users to the worklist. You assign users to a worklist via the SAP Easy Access menu: Financial Services Account Management / Master Contract Management Postprocessing Office Worklist Change Assignment. When a user starts a PPO transaction, for example, BCA_PPO2 with “Order Assignment” = 1, the user will only see PPO orders that are assigned to his or her worklists.
A PPO order is assigned to a worklist during the order creation. If the assignment of a business process to a worklist is missing in the configuration, a PPO order related to this business process is not assigned to a worklist during creation.
If you reassign a business process to another worklist, the existing PPO orders are not updated.
2.5 Errors Outside the Initiating Application Component
In banking services from SAP, processes communicate either synchronously or asynchronously with other application components. Asynchronous communication means that the initiating process sends a message to another application component without expecting any response to that message. After an asynchronous message is sent, the initiating process continues. The asynchronous message is processed in the other application component. If there is an error during processing within the other component, the Error and Conflict Handler (ECH) takes care of it. The ECH passes all relevant information (including the processing data) to the PPO (default behavior). It is not necessary to activate PPO orders created by ECH.
Banking Services from SAP
Master Contract Management Application Component
Account Management Application Component
R
PPOECH
Inbound Proxy
Outbound ProxyApplication Application
Error Outside the Initiating Application Component
PPO orders created by ECH provide more possibilities than classical PPO orders. For instance, ECH PPO orders can be reprocessed manually and/or automatically. Depending on the kind of error, automatic reprocessing can successfully process orders without user interaction, for example, if there is a lock situation.
For automatic reprocessing, report /SAPPO/RESUBMIT_ORDERS_2 should be scheduled as a periodic job. The report can run several times during end-of-day processing. At the very least, it should run once at the end of end-of-day processing.
A mass run will end with application return code = 0 (assuming there are no errors within the
application component) if there are errors outside the initiating application component. Therefore, it is mandatory to monitor PPO, RFC queue (transaction SM58), and PI/XI queue (transaction SXMB_MONI).
In the IMG you can define, per component and business process, a resolution strategy for the ECH PPO orders. If nothing is defined in the IMG, the general default resolution strategy is applied. The default resolution strategy is:
Create PPO orders. Allow automatic and manual retry. Allow manual finish and fail. Use no residence time and no resubmission group.
Use the following IMG activity to define your own resolution strategy if the default does not fit in your case: Cross-Application Components General Application Functions Error and Conflict Handler Define Resolution Strategy.
Here is an example of how a resolution strategy might look:
ECH Customizing
For the business process MIF_BAC_0005, Actions for Participant Account for Combined Settlement, ECH orders are created in case of errors. The orders will be stored in the database because the Persistent checkbox is selected (this should always be the case). The orders are assigned to the resubmission group “S30 Hourly.” This submission group can be used as selection criteria in a variant of report /SAPPO/RESUBMIT_ORDERS_2. A periodic job for report /SAPPO/RESUBMIT_ORDERS_2 should be scheduled. The scheduled job should run hourly and should use the variant with resubmission group S30. Because the repeat mode is set to “3 Automatically and Manually,” the report will repeat the orders automatically. A user can also repeat the order manually out of the PPO. The confirmation mode is set to “0
No Processing.” This means that it is not allowed to finish this PPO order. In the context of business process MIF_BAC_0005, this means that no positive confirmation (everything is okay) can be sent to the original sender (in this case, the Master Contract Management component). The positive confirmation is only sent when the repetition is successful. This is useful for preventing inconsistencies.
But it is allowed to discard the order. If the order is discarded, a negative confirmation is sent to the original sender. This means that the sender has to make sure that the state before sending the message has to be restored. Discard is possible either automatically via report /SAPPO/RESUBMIT_ORDERS_2 or manually out of the PPO.
The residence time is four weeks. After four weeks, the order can be discarded automatically by report /SAPPO/RESUBMIT_ORDERS_2 if processing fails.
It is not recommended to use the transient resolution strategy, because it could lead to problems
during processing of messages sent via XI. Always use the persistent resolution strategy. Make sure that the Persistent flag is always selected; otherwise, no PPO order is created.
2.6 Errors “in Between” Application Components
In some cases, errors can also happen “in between” application components. This is the case if the initiating process sent a message but the message did not arrive at the target application component. The problem could be a communication error, for example, target system is not available, or the called function is faulty or not available.
Error “in Between” Application Components
For RFC-based communication, you can use transaction SM58 to monitor and analyze such calling errors. The transaction provides information about the called function, the error, and the target system. If the target system cannot be reached because the connection is not active, report RSARFCSE is scheduled automatically as background job and is called at regular intervals. If there is a problem with the called function (for example, syntax error or short dump) you must analyze the problem and correct the error. Check the runtime errors in the target system with transaction ST22 to get more information about the error. Once the
error is solved, you can restart the RFC via transaction SM58. Additionally, schedule report RSARFCEX, “Execute Calls Not Yet Executed,” as a periodic background job to restart aborted RFCs.
For message processed via the Process Integration Server (PI/XI), you can use transaction SXMB_MONI for monitoring and analyzing.
The mass run will end with application return code = 0 if there are errors “in between” application
components. Therefore, it is mandatory to monitor PPO, RFC queue (transaction SM58), and XI/PI queue (transaction SXMB_MONI).
2.7 Avoid Error Situations by Using Repeat Functionality of the Framework for Parallel Processing
To avoid errors resulting from lock situations, you can define the number of parallel and sequential repeats per application type in the Framework for Parallel Processing configuration (IMG: Financial Services Account Management / Master Contract Management Tools Parallel Processing Maintain Customer Settings for Application Types).
Setup of Direct and Sequential Repeats
The application itself makes the decision about the repeat behavior. The object can be repeated only if the application sets a certain status for an object within parallel processing.
Parallel repeat means that packages that include objects with a certain status are repeated in parallel (with the same number of jobs defined for the run) after all packages have been processed once. If a sequential repeat is defined, all packages that include objects with a certain status are repeated in one single background job after the parallel repeat(s).
Parallel Processing Framework: Dynamic Model (simple scenario)
Number of parallel jobs is defined by application type in IMG by customerIMG: Financial Services Account Management Tools Parallel Processing Maintain Job Distribution
Job 2
write
Package DB Table
Build Packages
Fetch Package
Process Package
read
Job 1 Job n
Finalize Run
Objects in Work List DB(optional)
read / write
[package selected?]
yes no
[repeat?]
Number of repeats defined via transaction bank_cus_pp/bank_cus_ppcper application type
Framework for Parallel Processing – Dynamic Model
2.8 Mass Run Monitoring with Transaction BANK_PP_MONITOR
Transaction BANK_PP_MONITOR can support you in analyzing erroneous mass runs. If a mass run ends with errors, the information about the mass run is stored by the Framework for Parallel Processing. With transaction BANK_PP_MONITOR you can, for example, see the number of created and processed packages of the mass run. You can also see the status of each object within a package.
You can also use this transaction to monitor the processing status during an active mass run. Navigate to the packages to find out how many packages have already been processed and how many packages still have an initial status.
Transaction BANK_PP_MONITOR is more a monitoring transaction then a transaction to analyze errors.
2.9 Repeat of a Mass Run with the External Run ID
If a mass run ends with a return code <> 0, the run can be repeated after the causing error is solved. If a banking service from SAP mass run provides the field External Run ID on the selection screen, it is possible to repeat the run with the external run ID of the original run.
External Run ID of a Mass Run
The advantage of repeating the external run ID of the original run is that the run is repeated with exactly the same input parameters of the selection screen, and the due objects do not need to be selected again by the application (the selection by the application may be a bit slower because of the complexity of the selection). The objects selected by the original run, which were not processed successfully, are stored by the Framework for Parallel Processing (PPF). During the repeat of the run, the stored objects are selected by the PPF and re-processed. If a mass run provides the external run ID, a run should be repeated with the original run ID in case of errors.
If a run ended with return code = 0, the usage of the external run ID for another mass run will not
repeat the original run. Instead a new run with the same ID is started. Once a run ends with return code = 0 administrative, data relating to this mass run is always automatically removed from the system.
An erroneous single object can also be repeated with a single run (if the application provides one)
when the causing error has been solved.
A mass run can also be repeated without using the external run ID of the original run. In this case, the application will select and process the due objects again.
Although a mass run ends with return code = 0, this does not mean that no errors occurred during execution. Therefore it is absolutely vital to monitor the system regularly, especially during and after the end-of-day processing.
The following table provides a list of transactions that can be used for monitoring and analysis:
See in the SAP Easy Access Menu, for example, Financial Services Account Management Logs
SXMB_MONI Integration Engine – Monitoring of messages send via XI/PI
BANK_PP_MONITOR Transaction to monitor mass runs
Schedule the reports /SAPPO/RESUBMIT_ORDERS_2, “Resubmission of Postprocessing Orders,”
and RSARFCEX, “Execute Calls Not Yet Executed,” as periodic job to avoid manual processing of errors if they are only temporary, for example, lock errors.
Banking services from SAP mass runs that are used in the end-of-day processing sometimes have dependencies between each other, for example, the creation of a bank statement should be done after the settlement, because the settlement results should also be visible on the bank statement. These dependencies have to be considered during the setup of the end-of-day job chain. A static view on the job chain should reflect these dependencies for example, by defining successor job(s). During runtime, a dynamic component has to be considered, too. This dynamic component is the status of a job. But not only the technical status of a job is relevant, but also an application-related return code. It could be that technically a job has ended without errors, but from an application point of view there might be errors. An external job scheduling tool should be able to cope with both, the technical job status and the application return code.
3.2 Technical Job Status of a Background Job
End-of-day mass runs are usually executed in background. The corresponding background job can have one of the following technical statuses.
Job Status Explanation
Planned (P) Steps that make up the job have already been defined, but the start condition has not yet been defined.
Released (S) The job has been fully defined, including a start condition. Without a start condition, a job cannot be released. Only an administrator or a user with appropriate authorizations for background processing can release a job, preventing unauthorized users from running jobs without approval.
Ready (Y) The start condition of a released job has been met. A job scheduler has put the job in line to wait for an available background work process.
Active (R) The job is currently running. Active jobs can no longer be modified or deleted.
Finished (F) All steps that make up this job have completed successfully.
Canceled (A) The job has terminated abnormally. This can happen in three ways: An administrator intentionally terminates a job with Transaction SM37,
Job Cancel active job A job step contains a program that produces an error System error or database problems
The status of the background job can be seen in the job overview (transaction SM37).
For banking services mass runs using the Framework for Parallel Processing you will find one start job and multiple main and end jobs in the job overview. Only the status of the start job is relevant for the job scheduling tool.
In addition to the technical return code, an application-related return code at the end of a batch job with the following values is provided by banking services mass runs:
Return Code
Description
0 Completed successfully: Processing of subsequent processes of the job net can continue. In the case of a restart of the job net, steps with this return value should be skipped.
2 Completed with warnings: Processing of subsequent processes can continue. In the case of a restart of the job net, steps with this return value should be skipped.
4 Completed with single errors: The mass run could not process all objects successfully. Errors occurred for certain objects. The system recorded these errors in the log. You can still continue the end-of-day processing but it is vital that you analyze the errors. If technically possible you can repeat the run once the errors are solved.
8 Terminated: Serious errors occurred when the system was processing the data. Job control should not continue with subsequent processes. First analyze the errors and do not continue with end-of-day processing until the errors are corrected.
99 Predefined value: Job has been started but no status was set so far. This means the report is still running. It could also be that the report terminated before a final status could be set.
In case of return code = 4, it is possible to change the return code to 8 based on the relation of due and successful processed objects. In the IMG activity Financial Services Account Management End-of-Day Processing Define Return for Mass Runs, you can set a relation between due and successfully processed objects with an upper limit (basis counter for the number of accounts processed) and the maximum proportion (percentage) up to which limit the run can be interpreted as “Completed with single errors, continuation possible” (return code = 4).
In addition to the maximum percentage, you can also specify an absolute maximum. In this case, the smaller of the two values is relevant on the highest permitted number of incorrect objects. If the percentage or the highest permitted number is exceeded, the application related return code is set to 8, which means terminated.
Here are some criteria for the decision on what to customize:
The standard (no customizing) delivers a return code 4 (individual errors) even if 100.000 out of 100.000 due objects have individual errors.
A certain number of single errors can indicate a kind of general error. In this case it makes sense to correct this error before continuing the job net.
It is not easy to define this “certain number.” The entries should be valid for small numbers of due objects (for example, settlements on a non-ultimo day) and for huge numbers (month-end) also.
Example
Basis Counter
Counter Relation
Upper Limit Limit Individual Error %
Absolute
ACCDUE ACCSUC 10.000 5
ACCDUE ACCSUC 100.0000 5 1.000
ACCDUE ACCSUC 5 1.500
Up to a limit of 10,000 due accounts, or a maximum of 5% of the due accounts, the process is handled as individual error (application return code = 4); if more accounts are affected, this counts as a termination error (application return code = 8).
At the end of a mass run the application-related return code is set by checking the customizing table mentioned above.
3.4 Handling of Job Status and Application Return Codes by an External Job Scheduling Tool
The application return code is transferred to the background job and stored together with other job information. This is done in the business transaction event (BTE) 0BANK015. The standard function module that is called at the end of a banking services mass run is STD_PROCESS_0BANK015. The function module calls the relevant function module to transfer the return code to the background job.
The external job scheduling tool can retrieve the application return code as well as the technical job status with the BAPI BAPI_XBP_GET_APPLICATION_RC.
The technical job status is provided in the exporting parameter STATUS. The value in field STATUS can be mapped to the job statuses mentioned above, as follows:
P = Planned S = Released/Scheduled Y = Ready R = Active/Running F = Finished A = Canceled/Aborted
The application-related return code is provided in the exporting parameter APP_RC.
Depending on the combination of the technical job status and the application-related return code, the job scheduling tool has to decide if the successor job can be started or not, for example, if the application return code = 4 and the technical job status = F (finished), the successor job can be started. Therefore the external job scheduling tool has to be able to interpret the two return codes correctly.
Example
Technical Job Status
Application return code
Result in the job control tool
Possible reactions of the job control tool
F = finished 0 – Completed successfully
OK Start next job(s)
2 – Ended with a warning
OK Start next job(s)
4 – Completed with individual errors
OK Start next job(s)
With the possibility to start this job later after having corrected the objects
8 – Terminated NOK - stop Restart this job or start next job(s) after analysis of the error
A - canceled 0 – Completed successfully
NOK - stop Restart this job or start next job(s) after analysis of the error
2 – Ended with a warning
NOK - stop Restart this job or start next job(s) after analysis of the error
4 – Completed with individual errors
NOK - stop Restart this job or start next job(s) after analysis of the error
8 – Terminated NOK - stop Restart this job or start next job(s) after analysis of the error
3.5 External Job Scheduling Example: Return Code Handling with Central Process Scheduling by Redwood for SAP NetWeaver
The SAP Central Process Scheduling application by Redwood for SAP NetWeaver is able to handle return codes, the technical job status, and the application-related return code. The job status and the application return code influence the processing behavior of the whole job chain. To understand the processing behavior of a job chain in SAP Central Process Scheduling, the basic principal of a job chain is be explained first.
A job chain in SAP Central Process Scheduling consists of three elements: The job chain itself
The job chain consists of several steps. The steps are processed one after the other. Steps
A step consists of several jobs. All jobs of a step are executed in parallel. Jobs
A job represents a report that is started in the back-end system with specific parameters, for example, a variant.
Example of a Job Chain Definition with SAP Central Process Scheduling
A job chain consists of n steps. Once a step is processed successfully, the next step is processed. A step consists of m jobs. A step is processed successfully if all jobs within the step are processed successfully. All jobs within a step are processed in parallel. A job chain is finished successfully if all steps are completed successfully.
So the overall status of a job chain is derived from the status of the single steps within the job chain. The status of a step is derived from the status of the single jobs within the step.
For a single job, the overall job status is derived from the technical job status and the application-specific return code. The derived status could be one of the following:
Status Description
Completed Process execution finished successfully.
Error The execution of the process failed.
Killed The process was terminated while it was running.
Unknown The service was terminated while the process was running. It can occur that the job gets deleted in the SAP system before the final status has been retrieved by SAP CPS. In this case, the job will get the status Unknown in the job monitor.
For the application return code = 4, the overall job status “Error” is derived. The status of the step and the job chain is also “Error.” Due to the fact that the step has status “Error,” the successor steps are not processed.
As mentioned above, an application return code = 4 indicates that single errors occurred. As long as the technical job status is “Finished,” the job chain can be continued. SAP CPS offers several possibilities to react on errors. One possibility is to use so-called “Status Handlers” on step level.
Final Status Handlers
On step level you can define what to do in case of errors. The final status handler “On Error” can be used to define what do to. If you are sure that no critical reports are included in this step you can set, for example, the action “Continue” to continue with the next step.
Another possibility is to use return code mapping within the job definition.
With the above setting, mass runs that end with an application return code 0, 2, or 4 will end with an overall status “Completed” (assuming the technical job status is “Finished”). So if all jobs within a step end with application return code 0, 2, or 4, the overall status of the step will be “Completed” and the next step can continue.
3.6 Simple Test Case to Verify If a Job Scheduling Tool can Handle Both Return Codes
To find out whether a job scheduling tool can handle both return codes, try the following:
Check the posting date of an existing bank posting area.
Create a variant for the program RBCA_DATE_POST_SET – “Set Posting Date for Payment Transactions” – with a new posting date in the past and deactivate the simulation flag.
If you run this report in dialog, you get the following error messages:
o BCA_BPARE009 - New pst date in bank pst area &1 must be after the one currently valid
o BCA_BASIS010 - Program completed with return code 8 / ABEND
Let the job control start the program RBCA_DATE_POST_SET with the variant you created. The result in SAP should be:
o Applicational RC (best to be found in the protocol of transaction slg1) = 8
The result in the job control tool should be a return code that means “stop – an error occurred in the last job.”
Job Status in Redwood
If the result in the job control tool stands for “everything OK,” you have an issue to solve.
3.7 Summary
Banking services from SAP mass runs provide an application return code in addition to the technical job status of the background job.
An application return code = 4 can be changed to 8 depending on the ratio of due and successful processed objects (depending on customizing).
Consider dependencies of mass runs during set up of the job chain. An external job scheduling tool should be able to cope with the application return code and
The following section provides an overview of dependencies that should be considered during the setup of an end-of-day job chain. In context with exception handling, it is important to know these dependencies, because in case of errors during the end-of-day processing it can be assessed how critical this error is for the whole job chain.
Besides the dependencies mentioned here, there may be also other organizational or technical dependencies that should also be taken into account.
4.2 Time-Based Dependencies
The end-of-day processing should take place within a certain time window. For instance, the end-of-day processing cannot start before the bank has physically closed its doors and, of course, the processing should be finished before the doors open the next day. To fulfill this requirement it has to be checked which end-of-day activities can be done in parallel. Furthermore, a proper hardware and system setup is required, for example, enough background work processes.
4.3 Date-Based Dependencies
One question to be considered during the setup of an end-of-day job chain is: “What should be processed or posted with which date?”
At the end of the day the bank needs a basis for calculating interests or “counting” the money of the accounts and reconciling against the general ledger. But due to the fact that nowadays a bank is “open” for customers 24/7, there is a need to handle postings that are performed during the end-of-day processing hours of the bank. Nevertheless, the bank has to fulfill the same legal requirements (or even more) on a daily basis. A “bank day” does not exactly correspond with the calendar day of the real world but with the working days of the bank with a slight shift in times. So a day at the bank may end earlier than the real day. The step of closing a day is called the “cutoff.” Banking services from SAP works with three cutoff dates.
1. Posting date for payment transaction
After changing the date it is not possible anymore to post transactions with an “old” posting date. This is the basis for being able to calculate interest. All transactions posted after cutoff are not relevant for the settlement (assuming the value date is the same or greater than the posting date), because the posting process uses the new posting date.
Advantage: It is not necessary to stop the system for postings.
The Assign Present Method “posting date” for accounts and master contracts (IMG: Financial Services Account Management Contract Management General Settings Assign Present Method) synchronizes the validity of master data changes with the posting date.
19:00: change of a limit from 2.000 EUR to 5.000 EUR of account 1
20:00: change of posting date from 15.05.2009 to 16.05.2009
21:00: change of a limit from 5.000 EUR to 1.000 EUR of account 2
The new limit from account 1 is valid from 15.05.2009, and the one from account 2 from 16.05.2009, although the change was made before midnight.
2. End-of-day processing date
All postings belonging to the end-of-day process are posted with this date.
Only after having posted all related items will this date be changed according to the new posting date.
3. General ledger date
At the end of a day, after having posted everything, the GL day has to be closed.
This makes sure that no postings with the old day (backdate postings) are possible anymore.
It is the basis for calculating items for the GL transfer according to the rules defined in the customizing.
Most of the end-of-day reports have a dependency on at least one of the dates.
4.4 Process-Based Dependencies
Business processes may consist of several process steps. For each step an own end-of-day report may exist. Therefore it is important to perform the necessary steps in the right sequence. This logical sequence has to be reflected in the end-of-day job chain.
The following examples will point out important dependencies. The examples do not contain all reports that can be used in the end-of-day processing. Furthermore it is not mentioned in which time intervals the mass runs should be scheduled. The examples should support you in setting up the end-of-day job chain.
The sequence number (Seq#) in the tables below reflects the processing order within a job chain.
General Account Management report dependencies - FS-AM
The dependencies of mass runs are reflected in the setup of the job chain. The job scheduling tool that controls the processing sequence of the job chain also monitors the return code of the runs. As explained above, mass runs can end with an application return code = 4 (ended with single errors). In this case, successor mass run(s) can be executed. From a business process point of view, it might make no sense to process an object, for example, an account, when it was not processed without errors by a predecessor run. For instance, if the settlement of an account was not successful, it makes no sense to create the bank statement for this account, because the settlement results will not be on the statement. Banking services from SAP provides a functionality to implement this behavior. The setup can be done in the IMG: Financial Services Account Management / Master Contract Management Tools Parallel Processing Maintain Locks of Other Application Types Relevant for Application Type.
Example Account Settlement Account Statement
Locks of Other Application Types Relevant for Application Type
The first entry means: If an account has been locked by the account settlement mass run because of an error, the statement for this account will not be produced. This entry only makes sense if the statement must include the results of the settlement of the same day.
During the setup of an end-of-day job chain, certain dependencies have to be considered. These dependencies can be:
Time-based (for example, time window for end-of-day processing) Date-based (for example, which date is relevant for processing or posting) Process-based (for example, logical processing sequence of end-of-day reports)
Some end-of-days reports set locks to certain business objects in case of processing errors. The locks can be used to prevent successor activities to process the locked object.
The following list of end-of-day reports is based on banking services from SAP 7.0. The reports can also be found in the IMG: Financial services Account Management / Master Contract Management End-of-Day Processing Define Job Nets. Select Usable reports within the maintenance view.
Report Name Description Application Component
/FSPD/RIPD_MASS_RUN_PP1 Execute Payment Distribution FS-AM
/FSPD/RIPD_MASS_RUN_PP2 Execute Automatic Postprocessing for Payment Distribution
FS-AM
R_BCA_PRI_PP_PACKAGE_CN Adapt Contract to Product Pricing List FS-AM
RBAPA_TOOLS_PP_BAPA_PCO1 Update of Priority of Account Orders FS-AM
RBAPA_TOOLS_PP_BAPA_PCO2 Automatic Processing: Resubmission of Posting Control Orders
FS-AM
RBAPA_TOOLS_PP_BAPA_PCO3 Automatic Processing: Final Processing of Posting Control Orders
FS-AM
RBCA_ACCRUE_RUN_PP FS-AM: Transfer Postings to General Ledger
FS-AM
RBCA_BACKDATED_CHANGES Select Accounts with Backdated Changes
FS-AM
RBCA_BANO_RUN_PP Start Balance Confirmation Mass Run FS-AM
RBCA_BAST_RUN_PP Start Bank Statement Mass Run FS-AM
The following table provides a list of sources where additional information about end-of-day processing and job scheduling can be found.
Link Description
http://service.sap.com/solutionmanagerbp
(select “Banking” as filter value for “SAP Solution”)
Banking Services best-practices documents
http://www.sdn.sap.com/irj/sdn/nw-scheduling The SAP Central Process Scheduling application by Redwood on the SAP Developer Network. The page includes also a link to the latest XBP documentation