Kontakt

Ansicht
Dokumentation

PR_GPA_EXEC_PLANNER - Master report for parallel bckg execution of GP on a list of systems

PR_GPA_EXEC_PLANNER - Master report for parallel bckg execution of GP on a list of systems

rdisp/max_wprun_time - Maximum work process run time   Vendor Master (General Section)  
This documentation is copyright by SAP AG.
SAP E-Book

Purpose

PR_GPA_EXEC_PLANNER is a report that helps you to execute a guided procedure in background mode on a possibly huge list of chosen systems. The first stepis to define a report variant by executing the report in dialog mode and by using the F4-helps that are available for most of the input parameters. In dialog mode, the report can be executed in "Simulation" mode to get an idea on the selected systems and on the number of child jobs required for the global processing of the GP, according to the input parameters defined. It's not possible to execute a GP in dialog mode.

Then when everything has been defined in a variant (GP to execute, list of systems in the scope of the GP, emails recipients for successful and unsuccessful GP executions, emails content from existing templates, child jobs control parameters), the second stepis to create a corresponding so-called 'Master' background job in SM36 transaction executing the PR_GPA_EXEC_PLANNER report with the variant defined before.

When executing the master job in background, the whole process can be divided into the following steps:

  • 1. Selection of the systems in the GP scope according to the specified system filters and data separation values

  • 2. Partition of the selected systems into smaller subsets of systems belonging to the same customer and datacenter, and eventually not exceeding a specified number (may be required to control the size of the emails that will be sent afterwards)

  • 3. Dynamic runtime creation of background child jobs for each subset of systems defined in above step 2, executing PR_GPA_EXEC_JOBinternal GPA planning management report with the appropriate dynamic variant, but without start condition yet defined (status = scheduled)

  • 4. Main loop controling the execution of all child jobs in the defined execution window (= duration of the master job), taking care of the number of simultaneous child jobs running in parallel, and starting new jobs as soon as a new job position is available; this step terminates either when all child jobs to execute are finished (successfully or not), or when the global processing time exceeded the maximum duration specified in the variant (in that case the child jobs that are still running are stopped by the master job).

  • 5. Last step is performing some post-processing operations, like sending an email to admin users in case of error during the execution of child jobs, optional removal of "scheduled" jobs that were not started due to time limit exceeded, or copy of child jobs logs into the logs of the master job.

Each child job executing PR_GPA_EXEC_JOB report is an independent processing unit reponsible for executing a GP on a reduced scope of systems, for one single customer and datacenter. Child jobs are started only by their master parent job, and can be stopped by the parent in case the processing time exceed the time limit. Child job names are defined by the following rule:

___

As job names are limited to 32 chars, master job name and datacenter names can be truncated. Jobs are processed from lower to higher indexes.

Child job processing can be divided into following steps:

  • 1. Check input parameters and generate log messages in case of any error (jobs logs in SM37 and application logs in SLG1)

  • 2. Loop on all systems in the reduced scope and execute the GP on each system

  • 3. Build the final report of the GP execution for every system

  • 4. Send the built reports to specified email recipients coming from the master job, either one by one, or all attached into a single email

  • 5. Again the last step is for the post-processing: in case of exception raised, send an email to admin users with the internal error.

Integration

The UI for putting in place GPA planning management is based on SM36 transaction, which allows to create the master job schedule. Just enter an appropriate master job name that you can use later to reconize your background processes in SM37 or SLG1 transactions. Remember that the master job name can be truncated when creating the child jobs names, therefore it's not a good idea to define a long job name for the master job. We recommend not to exceed 10 characters.

You can specify an "Executable Target" (either a single server name, or more interestingly a server group (= set of server names on which the background jobs will be executed) that you will reconize by the '<' and '>' characters). By doing so, the child processes created by the master job will also use this "Executable Target" for globally load-balancing the execution of the GP. Leaving the executable target empty will automatically load-balance the GP execution on all known servers. For more details on the background load-balancing algorithm, see SAP note24092.

Remark: the master job class (= priority queue, 'A' for high-prios, 'B' for medium-prios and 'C' for normal-prios) is not transfered to the child jobs, which are always defined with a 'C' job class.

Then click on "Step" button to attach a report to your job. In the "Create Step" popup window, you have to enter an execution user name (this user should have all the required authorizations to execute the GP on the system, normally this is your own user), "PR_GPA_EXEC_PLANNER" for the ABAP program name and the program variant that you want to use (if you enter first the prgram name, then you will get the possible variant names from the F4-help). Keep 'EN' for the language, GP planning management is currently not handling several languages (this may change in the future!). Check and save.

Last step is to define a start condition. Then click on the corresponding button and choose between an "immediate start" or a scheduled start with "Date/Time" button. Also consider the "Periodic Job" checkbox to define a periodicity for your job, settable via "Period Values" button. Nevertheless we recommend to start with a non-periodic job for the first GP execution.

Finish the master job definition process by saving. You can then monitor the execution of your job from SM37 transaction (you can jump from SM36 by using "Job Selection" button).

Prerequisites

  • Definition of the PR_GPA_EXEC_PLANNER report variant(s)
  • Definition of the planning management master job(s) in SM36 executing PR_GPA_EXEC_PLANNER report with appropriate variant(s)

Features

Selection

Description of the selection screen of PR_GPA_EXEC_PLANNER report:

  • Guided Procedure ID(GP_ID parameter): contains the GUID of the guided procedure to execute. F4-help is available to get the full list of active version of available guided procedures on the system. Just double-click on the guided procedure to be used (this will update the description displayed on the right side), or press the "cancel" button to close the F4-help without changing the GP value. Remark: GP version is not part of the report variant, because the "active" version is always retrieved on the fly when needed (for display or processing)
  • Data Separation fields: use them to limit the selection of systems for the GP scope to the systems of specific customers or datacenters. Empty values means no restriction.
  • Customers (CUSTIDS select-options): customer names to be used/not used; multiple values are allowed, '*' wildcards are allowed, intervals are not allowed but excluded values are possible; F4-help listing all possible customer names and allowing multiple selections via the checkbox column is also available. Values displayed in the F4-help are influenced by the already specified datacenter values, only the customers belonging to the specified list of datacenters are displayed.

  • Datacenters (DATACIDS select-options): datacenter names to be used/not used; same as for customers; values displayed in F4-help are influenced by customer list already specified.

  • Scope of Technical Systemsfilters:
  • Long SIDs(EXTSIDS select-options): list of long/extended system ID part of the GP scope; F4-help listing all the possible long system ID values is available; in case no customer and datacenter value was specified, a warning popup telling that using the F4-help will take some time is displayed (potentially more than 1 minute), and the user can cancel the F4-help usage; returned systems results are buffered so that next time the F4-help is called the reponse time is much faster;

  • System Types(SYSTYPES select-options): LMDB types of technical systems (ABAP, JAVA, HANADB...); F4-help allowing to select multiple values via checkboxes is available. '*' wildcards are allowed, intervals are not allowed but excluded values are possible; specified values are influencing the F4-help list of long SIDs.

  • IT Admin Roles(ITROLES select-options): LMDB IT Admin roles of technical systems (PROD, QA, DEV...); F4-help allowing to select multiple values via checkboxes is available. '*' wildcards are allowed, intervals are not allowed but excluded values are possible; specified values are influencing the F4-help list of long SIDs.

  • IT Admin Priorities(ITPRIOS select-options): LMDB IT Admin priorities of technical systems (Very High, High, Medium...); F4-help allowing to select multiple values via checkboxes is available. '*' wildcards are allowed, intervals are not allowed but excluded values are possible; specified values are influencing the F4-help list of long SIDs.

  • IT Admin Lifecycle Status(ITLSTATS select-options): LMDB IT Admin lifecycle statuses of technical systems (Planned, Ordered, Installed...); F4-help allowing to select multiple values via checkboxes is available. '*' wildcards are allowed, intervals are not allowed but excluded values are possible; specified values are influencing the F4-help list of long SIDs.

  • Types of database(DBTYPES select-options): types of database used by the technical systems (Oracle, MaxDB, Microsoft SQL Server...); F4-help allowing to select multiple values via checkboxes is available. '*' wildcards are allowed, intervals are not allowed but excluded values are possible; specified values are influencing the F4-help list of long SIDs.

  • Emails parameters:
  • TO (MAILTOS select-options): list of email addresses to which the GP reports should be sent according to the "TO" email rule; no F4-help available

  • CC (MAILCCS select-options): list of email addresses to which the GP reports should be sent according to the "CC" email rule; no F4-help available

  • BCC (MAILBCC select-options): list of email addresses to which the GP reports should be sent according to the "BCC" email rule (hidden addresses); no F4-help available

  • Email Template (MAILTPL parameter): SE61 document to be used for the email subject and content when sending the report results; use the F4-help to get the available compatible SE61 documents (taken from the SE61 general texts with ID starting with "GPA_MAIL" prefix); to create a new email template, just make a copy of "GPA_MAIL_TEMPLATE" SE61 general text (name it with a GPA_MAIL prefix!) and modify it by slightly changing the text content. Be careful with the modification you make, do not destroy the HTML structure, nor the and tags, be careful with the dynamic placeholder values that should belong to a list of allowed placeholders: As of the current version, these placeholders are accepted:

  • $GP_TITLE$: GP Title

  • $MO_IDS$: A concatenation of system IDs

  • $STATUSES$: The consolidated status for all the GP executions on all the given systems

  • $MO_ID$: The system ID

  • $MO_DESCRIPTION$: The system description

  • It is also worth noting that we have created tags to allow looping on different elements. For example we have the tag FOREACH_GP_INSTANCE. All the content between and will be repeated for the list of the GP instances we have. The same logic applies to the tag

  • ADMIN Receivers (MAILADM select-options): list of email addresses which will receive notification of errors by email (either issues with the jobs scheduling process, or issues with the execution of GP in the child job)

  • ADMIN Email Template (ADMTPL parameter): SE61 document to be used for the email subject and content when sending one error notification; use the F4-help to get the available compatible SE61 documents (taken from the SE61 general texts with ID starting with "GPA_MAIL" prefix); to create a new email template, just make a copy of "GPA_MAIL_TEMPLATE_ADM" SE61 general text (name it with a GPA_MAIL prefix and also use ADM in the SE61 ID !) and modify it by slightly changing the text content. Be careful with the modification you make, do not destroy the HTML structure, nor the and tags, be careful with the dynamic placeholder values (especially $EXCEPTION_TEXT$) that should belong to a list of allowed placeholders:

  • $GP_TITLE$: The GP Title

  • $MASTER_JOB_NAME$: The master Job Name

  • : a helper to repeat the content between the and

  • $EXCEPTION_TEXT$: The text of the exception

  • Send one email per system (ONEMAIL parameter): if this flag is checked, then email recipients for the GP reports will receive a mail for each system, otherwise they will receive a single email per child job

  • Background Jobs Control parameters:
  • Maximum global time duration(DURVAL and DURUNITparameters): maximum duration of the process, 8 hours by default. F4-help is available for the time unit of measure. This is to guarantee that the child jobs executing the GP and building the GP reports can stay under control. This parameter has also to be adjusted according to the master job periodicity.

  • Maximum number of jobs in parallel(MAXJOBS parameter): to limit the impact of GP planning management on the system, to avoid taking too many background ressources. Default value is 5, and cannot exceed 15.

  • Maximum number of systems per child job ( MAXOBJS parameter): This parameter is for controlling the size of child jobs, in terms of processing ressources and size of emails to be sent. Depending on the Solution Manager system on which GP Planning Management is used, it may make sense to use this paramet =5 systems, as we don't have the data separation concept, this parameter is absolutely required).

  • Maximum number of systems in total (MAXTOTAL parameter): Set this parameter if you want to globally limit the number of technical systems on which the guided procedure will be executed. When this number is exceeded, the remaining systems are simply ignored during the creastion of the child processes. Leave this parameter empty (default value) if you don't want any limitation.

  • Delete jobs that were not started due to lime limitation(DELJOBS parameter): check this option to avoid a backlog of "scheduled" jobs in SM37, that will stay for ever if nobody explicitely delete these entries in SM37. But it may also make sense to keep these job entries without start condition if the processing duration was not large enough, because they can be easily be started manually from SM37. Indeed these jobs contain all variant information respective to PR_GPA_EXEC_JOB child report.

  • Copy child jobs logs into master job logs(COPYLOGS parameter): check this option if you think it make sense to have all the child job logs inside the single job entry of the master job.

  • Execution Mode:
  • Simulation Mode(SIMUL parameter): check this option to get a precise idea on the number of the systems that will be processed by the GP and on the number of required jobs. When defining a new variant, always use this option at least once.

Standard Variants

No standard variants are delivered with the PR_GPA_EXEC_PLANNER report..

Output

Outputs of this reports are:

  • In simulation mode, list of systems and child jobs + few statistical values.

  • Jobs logs in SM37

  • Application logs in SLG1: use SM_GPA as object and SM_GPA_PLAN_MAN as subobject, then filter by external ID which is defined as / , with "MASTER:" prefix in case of SLG1 logs for the master job (indeed there is one SLG1 file per every job running).

  • The emails sent containing the GP HTML reports as attachments and the possible error messages.

  • The GP reports accessible via the GP logbook using the appropriate URL.

Activities

Example






Addresses (Business Address Services)   Addresses (Business Address Services)  
This documentation is copyright by SAP AG.

Length: 21012 Date: 20240531 Time: 193654     sap01-206 ( 414 ms )