Durch den Austausch des Jobsteps TradeItemManagerDirectSql mit dem TradeItemManagerFillCache und TradeItemManagerBookCache (wie in Abbildung 1 und 2) können die Daten direkt in der ArticlePool_ArticleCache Tabelle verbucht werden.
Vorsicht: Es kann zu Problemen führen, wenn beim Verbuchen der Daten durch den TradeItemManagerBookCache-Jobstep ein Fehlerfall auftritt und danach ein ReRun auf den Job ausgeführt wird. Durch das Auftreten eines Fehlers bein Verbuchen wird die entsprechende Cache-Tabelle von der aufgerufenen gespeicherden Prozedur nicht geleert. In diesem Fall können nicht noch einmal die Daten des verarbeiteten Dokuments in die Cache-Tabelle eingefügt werden, ohne eine Primär-Schlüssel-Verletzung hevor zu rufen. Um diesen Fall zu vermeiden sollte vor Inbetriebnahme das Konzept für einen solchen Job-Aufbau mit der Pranke GmbH abgesprochen werden.
Abbildung 1

Abbildung 2

Der gesamte Job sieht jetzt folgendermaßen aus: Abbildung 3

Angetriggert wird der in Abbildung 3 im gelben Kreis liegende Job von dem äußeren Job, welcher den Delegator to ArticlePoolFillCache enthält. Der Äußere Job holt die Nachrichten ab.
Sobald alle Artikeldaten in der ArticlePool_ArticleCache-Tabelle sind, was durch das Delegieren auf den in Abbildung 3 dargestellen ArticlePool-Job im gelben Kreis geschehen ist, beginnt das Verbuchen der Artikel durch die zwei Jobsteps unterhalb des Delegators des Äußeren Jobs.
Hinweis: Der Erste Jobstep ist ein TradeItemManagerFillCache, der eine StoredProcedure „ArticlePool_ClearCache“ zum löschen seines Inhaltes ausführt, sobald der Job gestartet wird. Damit wird sichergestellt, dass kein Fehler durch doppelte Einträge im Cache hervorgerufen werden, falls eine Exception währen des Verbuchens von Artikel in den ArtiklePool auftritt.
Da die zur Verbuchung relevanten Jobsteps durch einen Lock-Mechanismuns geschützt sind, können diese Jobs nur einmal zur geichen Zeit laufen.