Im Workflow nach Fehler wieder aufsetzen

Für meine Erinnerung, das muss ich ausprobieren ob es was bringt:
How do I resume a failed process flow?
Hat jemand damit schon Erfahrungen gemacht?

[via Klein Oracle denkraam]

SQL*Plus im Workflow aktivieren

Gut zu wissen, sollte der Fehler: 'RPE-02248: For security reasons, activity operator SQLPlus has been disabled by the DBA' bei der Ausführung von SQL*Plus aus einem Oracle Workflow beim OWB auftreten, dann fehlt die Freigabe für diesen Dienst.

Seit OWB 10gR2 sind aus Sicherheitsgründen die Aktivitäten Shell, FTP und SQLPlus standardmäßig deaktiviert. Durch ändern der Datei 'OWB_HOME/owb/bin/admin/Runtime.properties' können diese aktiviert werden. Die zu ändernden Zeilen stehen am Ende der Datei. Anschließend muss der Runtime Service (OWB_HOME/owb102/owb/rtp/sql/stop_service.sql bzw. start_service) neu gestartet werden.

Workflow kann nicht deployt werden..

diese Meldung (RPE-02062: ItemType xyz cannot be dropped as it has running Processes) kennt wohl jeder der mit dem OWB gearbeitet hat.
Die Bedeutung der Meldung ist klar, es läuft noch ein entsprechender Prozess und erst wenn dieser beendet ist kann der Workflow (WF) neu erstellt werden.

Nun kann man warten bis der laufende Prozess beendet ist oder man bricht im WF-Monitor diesen Prozess gezielt ab. Soweit ist alles gut.
Was aber wenn im WF-Monitor kein laufender Prozess mehr angezeigt wird?
Offensichtlich hängt da im WF-Repository noch eine (Teil-)Information, die einen laufenden Prozess vortäuscht.

Mit dem folgenden Statement können im OWF_MGR die laufenden Prozesse aus dem WF-Repository abgefragt werden.

select item_type, item_key, begin_date, end_date, activity_status
from wf_item_activity_statuses
where activity_status<>'COMPLETE'

Als Ergebnis erhält man eine Liste der laufenden Prozesse. Mit dem so ermitteltem item_type und item_key kann nun der blockierende Prozess abgebrochen werden.
Dazu benutzt man die Procedure WF_ENGINE.ABORTPROCESS(ITEMTYPE, ITEMKEY) im OWF_MGR.
Anschliessend sollte das Deployment wieder funktionieren.

Auditdaten des Workflows ohne Störung der Ladeprozesse löschen

In der Version 10g des Oracle Warehouse Builders hat Oracle eine Möglichkeit geschaffen den neuen Scheduler der Oracle Datenbank für die Automatisierung der Workflows zu nutzen. Das funktioniert gut.

Vielleicht sollte ich sagen unter normalen Umständen gut. In einem meiner Projekte wird alle paar Minuten per Scheduler ein Workflow gestartet. Das ist ok und läuft. Dabei werden dann allerdings auch entsprechend viele Auditdaten vom Workflow erzeugt. Die Menge wächst auch im kleinsten Loglevel rasch an. Ganz auf die Auditdaten verzichten wollte man aber auch nicht. Nach einger Zeit hat man daher die Auditdaten gelöscht. Schlagartig lief kein Workflow mehr! Warum?

Oracle hat die Verbindung des Schedulers mit dem Workflow über den OWB so eingerichtet, dass sich der Schedulerjob als Parent der zu startenden Workflows in den Auditdaten einträgt. Als Gruppierungselement ist das durchaus praktisch. Aber beim löschen der Auditdaten wird auch diese Parentid mit gelöscht und damit verliert der Schedulerjob seinen Bezug zu den Auditdaten. Das führt zu dem Effekt, dass der Schedulerjob anspringt, seine Parentid nicht findet und damit die Ausführung abbricht. Hier hilft nur ein stoppen und starten bzw. ein neues Deployment der Schedulerjobs aus dem OWB Controll Center heraus. Nur dann initialisiert sich der Schedulerjob wieder neu und er erhält eine neue Parentid.
Das Ganze ist sehr unpraktisch, könnte der Schedulerjob doch bei verlorener ID sich einfach selbst neu initialisieren. Aber das hat Oracle nicht vorgesehen.

Nun wollten wir aber die Auditdaten, möglichst störungsfrei für die Ladeprozesse, löschen können. Was tun?
Eine Erinnerung an die alte Jobsteuerung der Datenbank bringt die Lösung. In Kurzform: Die Schedulerjobs erstellt man per Skript selbst. Darin enthalten ist der Aufruf einer Procedure, die wiederum den eigentlichen Workflowjob startet. That's all.

Damit steht der Schedulerjob zwar nicht mehr in den Auditdaten, aber das störte hier nicht. Der große Vorteil, ich kann nun Auditdaten löschen wie ich möchte, ohne das die Ausführung der anstehenden Ladeläufe gestört wird. Der Schedulerjob startet ohne murren einfach den nächsten Workflowjob und kümmert sich nicht mehr um die alten Auditdaten.

Hier ein Muster für einen Schedulerjob ...

BEGIN
DBMS_SCHEDULER.create_job (job_name => '',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN owbrun.p_wf_execute(''''); END;',
start_date => trunc(SYSDATE),
repeat_interval => 'FREQ = Weekly;INTERVAL = 1;BYDAY=MON,TUE,WED,THU,FRI,SAT;BYHOUR=3,9,15,21;BYMINUTE=4;',
end_date => NULL,
enabled => TRUE,
comments => NULL
);
END;

.. und die verwendete Procedure zum starten des Workflows.

create or replace procedure p_wf_execute( p_wf_name VARCHAR2)
is
exec_return_code number;
Begin
-- Initialize Return Code
exec_return_code := wb_rt_api_exec.RESULT_FAILURE;
-- Start Workflow
exec_return_code := WB_RT_API_EXEC.RUN_TASK('', 'PROCESS', p_wf_name, ',', ',', 0, 0);
END p_wf_execute;

Das alles läuft stabil, wir können nun jederzeit in Teilen oder auch komplett die Auditdaten löschen. Die laufenden Ladeprozesse werden dadurch nicht gestört.