Falls Sie die Verbindung zu WebSphere Process
Server mit den traditionellen Adaptern herstellen, können Sie anhand des folgenden Algorithmus genauer nachvollziehen, wie
das WebSphere Process
Server-DataObject aus der WebSphere InterChange Server-XML erstellt wurde.
Diese Informationen erläutern, wo die Datenwerte platziert wurden und welche Datenwerte als
Ersatz für die in WebSphere InterChange
Server verwendeten Datenwerte gewählt wurden.
Allgemeine Informationen
- Um das Verb in 'ChangeSummary' festzulegen, erfolgen alle Einstellungen mit den APIs
markCreate/Update/Delete.
- Um das Verb in 'ChangeSummary/EventSummary' festzulegen, werden die Verben Create, Update und Delete in 'ChangeSummary' festgelegt, während alle anderen Verben in 'EventSummary' festgelegt werden.
- So wird das Verb aus 'ChangeSummary' abgerufen:
- Wenn 'isDelete' den Wert 'true' hat, lautet das Verb Delete.
Anmerkung: Der Wert von
'isCreate' wird ignoriert, wenn 'isDelete' den Wert 'true' hat. Dies könnte eintreten, falls die Erstellung markiert wurde, bevor das DataObject am Hub eintraf, wo es gelöscht wurde, oder falls sowohl die Erstellung als auch die Löschung im Hub stattfanden.
- Wenn 'isDelete' den Wert 'false' und 'isCreate' den Wert 'true' hat, lautet das Verb Create.
- Wenn 'isDelete' den Wert 'false' und 'isCreate' den Wert 'false' hat, lautet das Verb Update.
- Damit ein DataObject anstelle des beabsichtigten Update nicht als
Create identifiziert wird, müssen Sie bei aktivierter Protokollierung Folgendes ausführen:
- Protokollierung während der Erstellung des DataObject aussetzen
- Protokollierung bei der Aktualisierung des DataObject wieder aufnehmen (oder API markUpdated verwenden)
Ladevorgänge
Beim Laden wird eine Laufzeit-XML von WebSphere InterChange
Server in eine BusinessGraph AfterImage-Instanz
von WebSphere Business Integration geladen.
- Eine Instanz des entsprechenden BusinessGraph wird erstellt.
- Die Protokollierung von 'ChangeSummary' wird aktiviert, damit bei einer späteren Aktivierung die Einträge nicht gelöscht werden.
- Die Protokollierung von 'ChangeSummary' wird angehalten, damit keine unerwünschten Informationen in 'ChangeSummary' aufgenommen werden.
- Die Attribute des BusinessObject der höchsten Ebene werden im
DataObject erstellt (siehe Abschnitt "Attributverarbeitung").
- Falls das BusinessObject der höchsten Ebene untergeordnete BusinessObjects enthält, werden diese rekursiv verarbeitet.
- Die Attribute dieser untergeordneten BusinessObjects werden im
DataObject erstellt (siehe Abschnitt "Attributverarbeitung").
- Das Verb des BusinessObject der höchsten Ebene wird auf das Verb der höchsten Ebene
des BusinessGraph gesetzt und in den Zusammenfassungen festgelegt.
- Das Verb der untergeordneten BusinessObjects wird in den Zusammenfassungen festgelegt.
Speichervorgänge
Beim Speichern wird eine BusinessGraph AfterImage-Instanz von WebSphere Business
Integration in einer Laufzeit-XML von WebSphere InterChange Server gespeichert. Falls das eingegebene BusinessGraph kein AfterImage ist, wird eine Ausnahmebedingung ausgelöst.
Attributverarbeitung
- Alle Werte, die im Folgenden nicht behandelt werden, werden UNVERÄNDERT geladen/gespeichert.
- ObjectEventId wird aus/in 'EventSummary' geladen/gespeichert.
- Für CxBlank und
CxIgnore gilt:
- Auf der Konvertierungsseite des BusinessObject von WebSphere Business Integration werden CxBlank und 'CxIgnore' folgendermaßen festgelegt/angegeben:
- CxIgnore: Ist nicht festgelegt oder mit dem Java-Wert Null festgelegt
- CxBlank: Wert ist typabhängig (siehe Tabelle unten)
- Auf der Konvertierungsseite des XML-Dokuments von WebSphere InterChange Server werden CxBlank und CxIgnore folgendermaßen festgelegt/angegeben:
Tabelle 1. Festlegung von CxBlank und CxIgnoreTyp |
CxIgnore |
CxBlank |
Int |
Integer.MIN_VALUE |
Integer.MAX_VALUE |
Float |
Float.MIN_VALUE |
Float.MAX_VALUE |
Double |
Double.MIN_VALUE |
Double.MAX_VALUE |
String/date/longtext |
“CxIgnore” |
“” |
Untergeordnete BusinessObjects |
(leeres Element) |
nicht verfügbar |