Understanding the Different XBP Interface Releases
The BC-XBP interface, which allows external process schedulers access to CCMS Background Processing components of SAP Systems, has gone through three major upgrades. The releases are named after their version numbers: BC-XBP 0.1, BC-XBP 1.0, BC-XBP 2.0 and BC-XBP 3.0. All four revisions of the interface require certification.
Since the BC-XBP 3.0 interface is quite complicated we will follow the course of history and discuss the oldest interface first and then present the additional functionality of the later versions.
BC-XBP 0.1
The BC-XBP 0.1 release is strictly tied to SAP Basis releases 3.1 and 4.0. The BC-XBP 0.1 interface consists of a set of wrappers around some of the internal calls that were already supplied to ABAP programmers, and which are also used in the transactions that allow end users to submit background jobs.
BC-XBP 0.1 allows an external scheduler to:
- Create a job or modify a job and most of its attributes.
- Add, change and remove steps from jobs.
- Release a job and request it to be run now or as-soon-as-possible.
- Retrieve a job's definition, status, log, and spool files.
Customers that implemented interfaces using BC-XBP 0.1 quickly found that there were some minor issues with the functionality. Not all print parameters could be set using the external scheduler, and the job class was fixed to "C". Also, jobs could not be deleted by the external scheduler. Although no calls changed between Basis 3.1 and 4.0, some interfaces had different record structures. The most important change was the increase of the maximum job name from 8 characters in 3.1 to 40 in 4.0, and it was made possible to set the job recipient.
With BC-XBP 0.1 it was possible to schedule jobs from the external scheduler, but the SAP System remained leading since the scheduler could not even delete the jobs it started when it deemed these jobs should be deleted.
BC-XBP 1.0
The next version of the BC-XBP interface was released with SAP Basis 4.5.
The BC-XBP 1.0 version fixed most of the problems that were found with the 0.1 release, as it was now possible to delete jobs and set more print parameters (but still not all). Unfortunately it was still not possible to set the job class, and setting the job recipient was no longer possible.
BC-XBP 2.0
The BC-XBP 1.0 interface lived on in early releases of SAP Web Application Server with Basis releases 6.10 and 6.20. Support packages were quickly introduced that upgraded 6.10 and 6.20 to BC-XBP 2.0. As of early 2004, all SAP versions that are in "normal support" status have Support Packages that include BC-XBP 2.0. Thus, if you run release 4.6B or higher, and have the latest Support Packages installed, you have BC-XBP 2.0!
Note: You can verify that you have BC-XBP 2.0 with transaction SE38. If you can find an ABAP program named INITXBP2 then you have at least BC-XBP 2.0 installed.
An important step was made by SAP with BC-XBP 2.0. For the first time, the interface contained functionality that cannot be obtained from within SAPGUI. The CCMS scheduler by default runs with some disabled features.
Interception
The most important feature that was added with BC-XBP 2.0 is interception. The issue that it solves is the problem related to jobs that are scheduled in SAP directly and that are not under the control of an external scheduler. These jobs would then take up work processes that were meant for scheduled batch jobs.
The intercept concept only works in the presence of an external scheduler, and needs to be explicitly turned on. When turned on, the CCMS scheduler does some extra processing when a job's scheduled running time arrives. If interception is switched on, and the job was not scheduled by an external scheduler (for example Redwood Server), and the job is supposed to run now, then the job client, name and owner are compared to a list. If the job matches the list, it is not set to Ready but set to Scheduled and inserted into a list of 'freshly intercepted jobs'.
Redwood Server can then ask for this list of intercepted jobs and make its own decision on what to do with the jobs. As soon as Redwood Server has taken control of an intercepted job the SAP System will not report this job again the next time the scheduler asks for intercepted jobs.
Note: Jobs are not intercepted when they are created, they are intercepted when they are ready to run.
Since SAP was not able to introduce a new status in the batch job table for fear of breaking their own and other's applications, it had to re-use the Scheduled status in combination with the new intercept table. The result is that if an external scheduler asks for the status of an intercepted job it receives Intercepted, but the same job is Scheduled in tools that have not been modified. Since the online transactions are not modified, it means that any operator looking at the job with SM37 will see that the job is 'back' in the Scheduled status. This was very confusing, and SAP has addressed the issue in AS ABAP 7.1. If you do not have this release, Redwood recommend that all operators use the job monitor view to view the actual SAP job status.
There are three criteria that can be used to define which jobs should be intercepted by CCMS:
- Client.
- Job owner.
- Job name.
Wildcards can be used, such as U* for the job owner will match all users whose account starts with U. Based upon these criteria there are three useful policies that can be used for job interception:
No interception required
If there are no users in the SAP Systems that can release jobs, and no SAP applications are in use that create their own jobs, then interception serves no purpose and it does not need to be used.
Some jobs are intercepted
By carefully filling the criteria table, you can intercept only certain categories of jobs. For example, if you find that your financial end users are causing stoppages by ad-hoc selected jobs, you could put their usernames in the criteria table. Unfortunately the criteria do not easily allow you to match all background jobs started by SAP programs unless these have a job name that starts with a specific character string.
All jobs are intercepted
Usually the most useful policy is to intercept all jobs. When Redwood Server is used to do all batch job scheduling, the volume of jobs started outside of Redwood Server should be low. Every job started outside of Redwood Server has the potential of interfering with other jobs start time. To counter this, ensure every job is intercepted so that they will adhere to the Redwood Server Queue and resource settings, ensuring fair sequencing of all batch jobs. This is also true for background jobs started by DDIC.
Parent/Child jobs
By default, even with BC-XBP 2.0, the CCMS does not track whether a job is submitted by a job or something else. This is unfortunate, because it means that job chains in SAP cannot say "start this when that job is finished completely, including its child jobs", since CCMS does not even know what a child job was.
With the new parent/child functionality one can tell CCMS to store the fact of the parent/child relationship of jobs. CCMS itself still does not offer any "wait for job plus children" functionality, so an external scheduler is the only way this can be done.
When the parent/child functionality is switched on, Redwood Server can retrieve the parent/child relationship. As with interception, it tells CCMS when it has made a permanent record of this relation so that the CCMS does not report the relation again.
Examples of batch jobs that are now easy to do include processing batch input folders.
Functionality completeness
With BC-XBP 2.0 it is now possible to set the job class, recipient and all print parameters per job step. You can also trigger batch input sessions by scheduling the ABAP program RSBDCSUB with the job definition SAP_AbapRun.
Availability of BC-XBP 2.0
The BC-XBP release that is available depends on both the SAP Basis (Web Application Server) release and the Support Package level. BC-XBP 2.0, the current release, is available for all SAP Web AS Basis releases that were actively supported by SAP in early 2004. It has been ported to all releases older than 6.30 by means of Support Packages (see SAP Note 604496 ).
SAP has fixed several issues relating to BC-XBP 2.0 in later Support Packages. Redwood therefore recommends using the Support Package of at least the Redwood recommended SP in the table below.
| Release | Minimum SP | Redwood recommended SP |
|---|---|---|
| 4.6B | SAPKB46B56 | SAPKB46B56 and SAPKH46B60 |
| 4.6C | SAPKB46C41 | SAPKB46C46 |
| 4.6D | SAPKB46D35 | SAPKB46D35 |
| 6.10 | SAPKB61027 | SAPKB61038 |
| 6.20 | SAPKB62017 | SAPKB62033 |
BC-XBP 3.0
The latest release of the XBP interface offers additional functionality and improvements over XBP 2.0.
Note: Some SAP releases still report that they only support XBP up to 2.0, although they have XBP 3.0 as well. Execute INITXBP2 in transaction SE38; you should see three options for job interception and if that is the case you have XBP 3.0. You can force Redwood Server to use XBP 3.0 by specifying it in the SAP system object for job interception, event history and monitor synchronization.
Note: XBP 3.0 requires a logical system for the client, see Setting Up Logical Systems for more information on creating logical systems for clients.
Event History
XBP 3.0 introduces mapping of SAP events with external schedulers. Redwood Server allows you to map any event with a combination of SAP event and SAP event parameter. Wildcards can be used.
Spool Recipient
XBP 3.0 re-introduces the spool recipient which had been removed from the XBP 2.0 interface.
Variant Handling
XBP 3.0 introduces variant handling. You can now maintain variants from within Redwood Server, that is import, edit and save variants. You can also make use of temporary variants, which get deleted when the job finishes.
Interception
XBP 3.0 introduced the criteria table. The criteria table takes processing order into account and allows you to exclude certain jobs from interception. For example, you could intercept all jobs with a name starting with B except jobs starting with Back.
Availability of XBP 3.0
XBP 3.0 is available as of SAP Basis releases 7.0; it will be ported to a number of older releases via Support Packages. See SAP Note 961911 for more information.
Configuration
Configuration in SAPGui
You can enable XBP 2 and XBP 3 features using the ABAP INITXBP2, see Enable XBP 2.0 or 3.0 Functionality for more information.
Configuration in Redwood Server
Redwood Server will by default use the most advanced interface, being transports, followed by XBP releases in descending order. You can force Redwood Server to use a specific XBP version by specifying it on the tab of the Redwood Server SAP system object or by setting the SynchronizationMode registry entry.