Fast alle Kunden nutzen intensiv das Batch Management als Teil der SAP Basis, um ihre Prozesse automatisiert abzubilden. Obwohl im Vergleich schon relativ mächtig, könnte SAP funktional an manchen Ecken durchaus noch eine Schippe auf die SM36 drauflegen. Da sie das lange Zeit nicht tat, ging der geneigte Kunde davon aus hier tut sich nichts mehr. Und doch, vor einiger Zeit erschien ein kleines undokumentiertes Lichtlein am Horizont.
Update 18.08.2015: Nach Einsatz bei einigen Batchjobs stellt sich heraus, dass die Wiedereinplanung nicht immer zuverlässig funktioniert. Das Problem ist an SAP adressiert, sobald eine Lösung / eine Hinweiskorrektur verfügbar ist, werde ich diesen Hinweis hier wieder entfernen. Bis dahin, bitte ein Auge auf den Job halten.
Was Hänschen nicht lernt
Wie eingangs erwähnt spricht viel für die Nutzung der integrierten Hintergrundverarbeitung im SAP, denn funktional bringt diese bereits einiges mit: Jobs aus mehreren Schritten, (eingeschränkte) Möglichkeiten zur Job-Verkettung, umfangreiche Einplanungsmöglichkeiten inklusive Werkskalender, automatischer Versand von Ergebnis-Spools. Trotzdem gibt es Dinge, die andere besser können – zugegebenermaßen meist jene die nichts anderes als Process Automation tun, allen voran Redwood und Automic:
- direkte Job-Verkettung auch in mehrmaliger Ausführung
- status-abhängige Jobstarts (Vorgängerergebnisse auswerten)
- systemübergreifende Job-Verkettung
- komplexere Einplanungsmöglichkeiten (von bis Uhrzeit oder Datumszeiträume)
Für letztere Anforderung ist mir beim Stöbern im SCN nun erst vor kurzem ein praktisches Tool in die Hände gefallen, wozu ich jedoch keinerlei zusätzliche Dokumentation finden konnte: BTCAUX10. Scheinbar gibt es einen nicht freigegebenen SAP Hinweis 1527859 der den Suchbegriff enthält, Teil des 997328 ist er jedenfalls nicht.
Wann hätten’s denn gern?
Also hieß es Testen was das Zeug hält. Das Ergebnis: dieses Tool ermöglicht es, über die normalen Einplanungsmöglichkeiten hinaus zwei entscheidende Dinge zu tun:
- Beschränkung eines periodischen Jobs auf einen bestimmten Datumszeitraum
- Beschränkung eines periodischen Jobs auf eine bestimmte Uhrzeit-Spanne
Das funktioniert grundsätzlich folgendermaßen:
Der Report BTCAUX10 kann gefahrlos gestartet werden (ja, es gibt eine Selektionsmaske ;). Wie zu erwarten erhält er als Eingabeparameter den Jobnamen, Report/Variante, Einplanungsuser und die Periode. Schon der erste Startzeitpunkt zeigt eine interessante Neuerung: das letzte Ausführungsdatum darf 365 Tage nach dem ersten Datum liegen.
Das ist schon ungemein praktisch wenn ein 15 minütiger Job nur über den Zeitraum von 8 Wochen laufen soll, und man sich die dazu nötige Ausplanung partout nicht über diesen Zeitraum merken kann.
Die zweite sehr interessante Möglichkeit der Einschränkung ist die Uhrzeit (Time Interval), hier können Tageszeiten angegeben werden, zwischen denen der Job laufen darf (Use Restriction). So kann beispielsweise konfiguriert werden, dass ein regelmäßiger Consumption-Job alle zwei Minuten läuft, aber eben nur zu Produktionsschicht-Zeiten zwischen 06:00 und 22:00 Uhr.
Die ersten Einplanungen zeigen, dass er tatsächlich das tut was er verspricht. Nach korrektem Ausfüllen der Selektionsmaske (ich empfehle die Verwendung einer BTCAUX10 Variante, denn ich brauchte locker 10 Versuche bis die Parameter so passten wie angedacht) und einem beherzten Druck auf Ausführen wird im Dialog unter angegebenem Namen der Job eingeplant. Dieser besteht dann aus zwei Steps. Der erste plant den Nachfolge-Job ein, unter Berücksichtigung von Datums- und Zeiteinschränkungen. Der zweite enthält dann den angegebenen Step der eigentlichen Programmausführung.
Ein wirklich nützliches Hilfsmittel, was den SM36 Funktionsumfang sinnvoll erweitert.
Darf’s noch etwas mehr sein?
Aber perfekt ist es nicht. Was ist zum Beispiel, wenn ich einen Multi-Step-Job brauche oder einen anderen User in den Job-Steps haben will als den als Jobeinplaner angegebenen?
Auch hier hat sich eine Lösung gefunden. Der erste Step, der sich um die Einplanung des Nachfolgers kümmert, nimmt tatsächlich keine irgendwo anders abgespeicherte Job-Referenz als Vorlage, sondern den tatsächlichen Job. Wenn ich also in eine ‚released‘ Job-Instanz gehe und diese verändere, dann kopiert mir der erste Step bei Ausführung diese Änderungen auch in den Nachfolger.
So lassen sich durch Abändern des freigegebenen Jobs problemlos Steps einfügen und Ausführungsuser ändern (oder weitere Settings vornehmen die BTCAUX10 nicht in der Selektionsmaske vorsieht).
Ihnen schonmal viel Spaß beim Testen, wenn jemandem Probleme auffallen bin ich für Rückmeldungen dankbar.
