Skip to Content
Author's profile photo Martin Lauer

Job Interception: Controlling end-user scheduled jobs

Job Interception: Controlling end-user scheduled jobs

Controlling background jobs that are scheduled by end-users is one of the top challenges for customers. End-user scheduled jobs that bypass a central scheduling are undermining all efforts of controlling the batch workload on a backend-system. So especially during times like Period End Closing, end-user scheduled jobs have led to overload situations of customer systems. Besides the problem of undermining a meaningful workload distribution, jobs that are run outside a central scheduling tool are usually not covered by any Service Level Agreement and are hence not properly monitored by the corresponding scheduling team. End-user jobs are also nowhere documented and no error handling procedures exist. So even if these are covered by monitoring nobody knows how to react in case of an exception.

 

To make things more complicated, company policies often do not allow restricting the scheduling authorization of end-users. Now actually a technical solution to this problem exists since many years, but is unfortunately still widely unknown to most SAP customers: Job Interception. SAP introduced the job interception functionality for the first time already with the eXternal Batch Processing (XBP) interface version 2.0 in Q1/2003. Back then you could maintain entries in table TBCICPT1 in order to define which jobs should be intercepted. Every external scheduling tool certified for XBP 2.0 could get a list of intercepted jobs and (re-)schedule them according to defined rule-sets. Meanwhile the XBP version 3.0 was introduced which allows a more flexible maintenance of interception criteria via program CRITERIA_MANAGER.

 

This blog describes more details on how to configure job interception in combination with SAP Process Scheduling by Redwood.

 

Configuration on backend system:

For activating job interception on a specific backend-system you have to execute program INITXBP2 first. There you select either XBP 2.0 or XBP 3.0 depending on whether the interception rules should be maintained via table TBCICPT1 or via program CRITERIA_MANAGER. The later is only available for SAP_BASIS 7.0 or higher but is recommended when available. Instead of switching-on job interception manually an external scheduler like SAP Central Process Scheduling by Redwood can use function module BAPI_XBP_NEW_FUNC_CHECK to switch-on or switch-off the functionality.

 

Case 1: Maintenance via table TBCICPT1

  • n Go to transaction SE16
  • n Enter table name TBCICPT1
  • n Create a new entry which jobs and/or jobs of which user should be intercepted

Table TBCICPT1

 

Table Part 2 

 

An external scheduler like SAP Central Process Scheduling by Redwood would use function module BAPI_XBP_MODIFY_CRITERIA_TABLE in order to read or change table TBCICPT1, so no manual maintenance via transaction SE16 s necessary.

 

Case 2: Maintenance via program CRITERIA_MANAGER (recommended for SAP_BASIS 7.0 or higher)

  • n Add a new Criterion of Type “Interception”
  • n For this type: Add a new criterion specifying which jobs and/or jobs of which user and/or of which job calls should be included/excluded from job interception
  • n Activate the newly created profile

CM

CM - 2

CM - 3

 

While the criteria maintenance via table TBCICPT1 only allows a positive list, i.e. intercept all jobs that meet the criteria, the maintenance via CRITERIA_MANAGER also allows a negative list, i.e. intercept everything except the entries meeting the criteria. While the later maintenance provides more flexibility, in both cases the result is basically the same. The respective end-user can still schedule background jobs via transaction SM36 or by sending reports in the background but the respective job is no longer executed – it is intercepted!

Cm - 4

 

 

Configuration in SAP Central Process Scheduling by Redwood:

Now these intercepted jobs shall be picked up by SAP Central Process Scheduling by Redwood in order to (re-)schedule it in a controlled way. This is done via function module BAPI_XBP_GET_INTERCEPTED_JOBS.

 

In the Environment view from SAP CPS you go and edit the corresponding SAP system entry. Within the SAP System view you have to set the Job Handling to Intercepted.

CPS - 1

 

Within view XBP Job Control Rules you can then create different Control Rules where you define which intercepted jobs should be handled in what way, e.g. all end-user jobs could be scheduled via a certain Queue which has just a limited number of background work processes assigned.

CPS - 1

 

In that way SAP CPS picks up the intercepted backend jobs and schedules them anew.

CPS - 3

 

As a result you can now also see the changed status on the backend system. Instead of being intercepted, they are now scheduled and will run once the scheduling criteria are met.

CPS - 4

 

 

 

Summary: For many years SAP provides the possibility to technically intercept selected background jobs as part of SAP_BASIS with the XBP interface version 2.0 or 3.0. In combination with an external scheduling tool like SAP Central Process Scheduling by Redwood you can pick-up the intercepted jobs and schedule them in a controlled manner based on freely definable rule-sets.

The interception functionality was shipped in Q1/2003 with XBP 2.0

 

SAP_BASIS Release

Support Package

4.6C  

SP 41

4.6D  

SP 34

610

SP 27

620

SP 17

>= 640

from the beginning

 

Outlook: As already outlined in the SDN blog about SAP is first vendor to provide a comprehensive Job Management Suite, SAP will soon go even one step further. Besides intercepting jobs that have been already scheduled, SAP will re-direct end-users into a standardized job request form who are trying to access transaction SM36 or execute programs in background via transaction SA38. Then background jobs with a re-occurring scheduling will only get into the backend system in a very controlled and documented way. You will soon learn more about it in a separate SDN blog.

 

 

 

Corresponding abstract of SAP TechEd 2009 session in Phoenix and Vienna:

 

Job Management with SAP Central Process Scheduling and SAP Solution Manager

This session showcases the capabilities offered by SAP’s Central Process Scheduler by Redwood, to automate the background job processing in your landscape . Also showcased is the integration with SAP’s Solution Manager which provides end to end Lifecycle Management of your background jobs. The session will introduce submitting job requests through SAP Solution Manager and SAP CPS will be used by the administrator to intercept and schedule the jobs. Based on the job documentation created by SAP Solution Manager, the administrator can create Job Chains. SAP CPS allows administrators, to create and schedule Job Chains spanning across multiple systems using user defined jobs or jobs imported from the backend systems. Jobs can be monitored and the enhanced notification mechanism of SAP CPS allows administrators to be notified about failed jobs or job chains, in real time.

 

 

List of selected related SDN blogs:

Assigned Tags

      10 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sandra Rossi
      Sandra Rossi
      From my developer point of view, I think that XBP interface is also widely unknown from customer developers and basis teams (maybe except the name XBP for solution manager team). It's probably because XBP is not documented in sap library, and documentation still refers to "old-fashioned" BP_* function modules.
      Author's profile photo Martin Lauer
      Martin Lauer
      Blog Post Author
      Hello Sandra,

      you can find the BC-XBP documentation on SDN.
      Navigate to
      -> Certification and Partnership
      -> Integration and Certification
      -> Background Processing, Output Management and Test Tools
      and open the link to BC-XBP page:
      Background Processing, Job Scheduling (BC-XBP)

      From there you have access to the XBP documentation in its different version, e.g. 3.0:
      ftp://ftp.sap.com/pub/icc/bc-xbp/BCXBPDOC70V3.pdf

      Kind regards,
      Martin

      Author's profile photo Sandra Rossi
      Sandra Rossi
      Thank you Martin

      I have just checked on my system how XBP works from an ABAP developer perspective, it is easy!

      Below I indicate how I did = everything you already said + some minor points which may be of interest for ABAP developers who would like to use interception without a third-party software (why not).

      1) activate XBP using program INITXBP2

      2) define criteria interactively using program CRITERIA_MANAGER (or SE16 on table TBCICPT1, or programmatically via FM BAPI_XBP_MODIFY_CRITERIA_TABLE)

      3) launch job manually or via program, with option start immediately (just to better see how XBP intercepts it). If it satisfies criteria, the job is created with status "scheduled" (without any starting condition) and written to TBTCCTXT table with CTXTTYPE = 'INTERCEPTED'

      4) start it by calling successively these function modules:

      4-a) SXMI_LOGON with parameters EXTCOMPANY and EXTPRODUCT = blank, INTERFACE = 'XBP', VERSION = '3.0'

      4-b) BAPI_XBP_GET_INTERCEPTED_JOBS and parameter EXTERNAL_USER_NAME = requestor for docu only, to get the list of intercepted jobs (which should still have scheduled status at that time)

      4-c) BAPI_XBP_JOB_START_IMMEDIATELY with parameters JOBNAME and JOBNUMBER = the job name and number to start, EXTERNAL_USER_NAME = requestor for docu only

      4-d) SXMI_LOGOFF with INTERFACE = 'XBP'

      Note: the user may release the job manually from SM37, we may prevent it by removing authorization

      Author's profile photo Martin Lauer
      Martin Lauer
      Blog Post Author
      Author's profile photo Nanda Kumar
      Nanda Kumar

      Great Blog Martin.

      Thanks

      Nanda

      Author's profile photo Former Member
      Former Member

      Dear Martin,

      Can you help me?

      How to see history of change of profiles in CRIT?

      It is necessary to know events of activation, deactivation, modification of restrictions.

      Regards, Alexey.

      Author's profile photo Former Member
      Former Member

      Dear Alexey,

      We don't keep the history of changes, only the last change is logged.

      BR, Vladimir

      Author's profile photo Former Member
      Former Member

      Dear Vladimir. thanks for you reply.

      Please, express your opinion.

      I suggest to activate history of changes for the table BTC_CRITERIA (Selection Criteria: Criteria) in tr. SCDO.

      It will allow to registirirovat changes in the tables CDHDR/CDPOS.

      Regards, Alexey.

      Author's profile photo Former Member
      Former Member

      Dear Alexey,

          

      I think it would be better to activate history of changes for the table “BTC_CRITPROFILES”. You will log
      activations, deactivations and modifications (because modification is only
      possible after deactivation) of criteria profiles.

      BR, Vladimir

      Author's profile photo Volker Wieseler
      Volker Wieseler

      Its working fine for me for all kind of Jobs. But i need to block only periodic background Jobs scheduled by some users. So i need the DB Table TBTCO, because there is a flag for periodic job. But how can i use this table in CRIT? Thanks in advance!