Wir haben ein ähnliches Problem gehabt, da ein System alle verarbeiteten Dateien (200k+) auf einmal bereitstellt:

Statt die Daten direkt über die Aufgabe abzuholen läuft zunächst ein LISTFOLDER, um alle Dateien zu listen.
Dadurch erhalten wir eine Nachricht mit der Struktur
<ROOT>
<ITEM…/>
<ITEM…/>
…
</ROOT>

Anschließen splittet eine Transformation die Daten in Gruppen von je 5 Dateien.
Die folgende Nachricht hat diese Struktur:
<ROOT>
<GROUP>
<FILE…/>
<FILE…/>
</GROUP>
<GROUP>
<FILE…/>
…

Anschließend wird die Nachricht an eine XML Iteration übergeben, die nach dem Knoten GROUP durchgeht.
Erst innerhalb der Iteration erfolgt die Abholung der Daten und die eigentliche Verarbeitungslogik.

Dadurch kann ich die Anzahl an Schritten, die mit Anhängen arbeitet und diesen Fehler provoziert klein halten und auch die Anhanggröße recht überschaubar.

Vielleicht hilft Ihnen das als Idee weiter

im Moment gibt es keine Standardfunktionalität, die es erlauben würde, Anhänge auszulagern.

Der Vorschlag von Herrn Roth, die Daten zu zerteilen, ist natürlich eine gute Möglichkeit. Zusätzlich sehen wir noch folgende Ansätze um die Problematik zumindest abzuschwächen:

• Dem TC Server Prozess mehr Speicher geben
• In den Einstellungen des Managers das Speichern der Zwischenschritte deaktivieren (in der Serverkonfiguration unter „Prozesszustände speichern“), hierdurch verschlechtert sich allerdings das Fehlerhandling
• Das Einbauen eines Zwischenschritts mit einem File Adapter, der den Anhang für die Zwischenschritte außerhalb von TC ablegt und nur den Pfad im System hält

Wenn die volle Datenbank noch ein zusätzliches Problem darstellt, gäbe es zusätzlich noch die Möglichkeit, die Beräumungsgrenze herunterzusetzen, sodass archivierte Nachrichten weniger lange im Speicher aufbewahrt werden.

Hoffentlich kommen Sie damit erstmal weiter!

Viele Grüße,

Ihr TRANSCONNECT-Team
<p style=“margin: 0in; font-family: Calibri; font-size: 11.0pt;“></p>