Questions & Answers

[oliver]

Hallo Community,

folgende Situation:

• 1 Master-Projekt
  • Stellt Templates für Slave-Projekte per Paketverwaltung bereit
  • Hat die Template- und Daten-"Hoheit" über einen globalen DB-Layer, der auch in den Slave-Projekten verwendet wird
    • d. h. nur im Master-Projekt ist der entsprechende DB-Layer schreibend und mit Schema-Sync angebunden
• X Slave-Projekte
  • Erhalten Templates aus Master-Projekt per Paketverwaltung
  • Greifen auf den globalen DB-Layer lesend zu (der Layer ist also "Schreibgeschützt" und ohne "Schema-Sync" angebunden)
    • Alle Projekte sehen also im globalen DB-Layer die gleichen Daten.

Während der Entwicklung wurden noch nicht alle Slave-Projekte aufgesetzt. Nun, da das System kurz vor dem Production-Betrieb steht, sollen die restlichen Slave-Projekte erstellt werden. Die Frage ist, wie dies *mit möglichst wenig Aufwand* geschehen kann. Der angestrebte Ansatz ist, ein vorhandenes Slave-Projekt zu exportieren und den Export als Blueprint für die weiteren Slaves zu verwenden. Dies stellt sich jedoch als nicht so straight-forward wie erhofft dar. Folgendes sind meine bisherigen Beobachtungen:

• Ein Projekt, in dem ein DB-Layer lesend und ohne Schema-Sync eingebunden ist, kann nach einem Export nicht wieder importiert werden.
  • Startet man den Import eines solchen Projektes, kann für den lesend angebundenen Layer kein Ziel-Layer ausgewählt werden. (Warum ist das so?) Ohne Auswahl eines Ziel-Layers kann jedoch der Import nicht fortgesetzt werden.
• Stellt man den DB-Layer vor dem Export um auf "Schreibzugriff" und "Schema Sync", kann das Projekt zwar wieder importiert werden, jedoch wird hierbei für den DB-Layer ein neues Schema in der Datenbank erzeugt. Damit ist die Verknüpfung mit dem ursprünglichen DB-Schema verloren und der neue Slave kann nicht auf die über das Master-Projekt gepflegten Daten zugreifen.

Meine erste Idee für einen Workaround war nun, vor dem Export des Blueprints die Templates und Datenquellen für den globalen Layer zu löschen und diese nach dem Import über die Paketverwaltung wieder herzustellen. Da es jedoch zahlreiche Abhängigkeiten auf die DB-Templates gibt, liefe das darauf hinaus, nahezu alle Templates vor dem Export zu löschen. Dies zieht dann einen "Rattenschwanz" an manuellen Tätigkeiten nach sich, die für jedes importierte Projekt einzeln durchgeführt werden müssen. Genau dies möchte ich gerne vermeiden.

Was ist hier die Best-Practice? Ich halte diesen Anwendungsfall für nicht allzu abwegig, und würde annehmen, dass er durch das System unterstützt wird.

Vielen Dank und viele Grüße,

Tilman Linden

[rrichter]

Hallo Herr Linden,

im Prinzip ist das genau die richtige Vorgehensweise.

Meine Erfahrung an dieser Stelle zeigt aber, dass der Layer, auf den man einen lesend eingebundenen Layer mappen möchte (ob dies nun initial der selbe war oder nicht) ein Standard-Layer sein muss (also ein Layer, in dem der SCHEMA-Parameter gesetzt ist). Es werden beim Import für einen lesend eingebundenen Layer nur Standard-Layer zum Mapping angeboten.

Vermutlich haben Sie auf Ihrem Server nur DBA-Layer definiert, was Ihre zweite Beobachtung bestätigen würde.

Könnten Sie das einmal prüfen?

Viele Grüße,

Raphael Richter.

[oliver]

Korrekt, es sind alles DBA-Layer.

[rrichter]

Dann versuchen Sie bitte einmal, den lesend eingebundenen Layer als Standard-Layer zu definieren. Dann müsste sich dieser als Ziel für ein Mapping aus dem Export eines Slaves angeben lassen.

[oliver]

Ich habe nun zwischenzeitlich in diesem Thread: https://community.e-spirit.com/message/8621#8621 diesen Hinweis gefunden:

"also ist in dem exportierten Projekt "kein SchemaSync" (bzw. auch "schreibgeschützt") angehackt (und der in diesem Projekt verwendete Layer ist wahrscheinlich ein DBA-Layer, d.h. keine Angabe von "jdbc.Schema" in der Layerkonfiguration)?

Dann erwartet das System (völlig korrekt), dass auf dem Server ein Layer namens "p207812_207619" existiert, um dieses Projekt importieren zu können. Bitte also einen neuen Layer mit dem Namen "p207812_207619" anlegen (die Bezeichnung entspricht dem physikalischen Schema-Namen, in dem die Datenbank-Inhalte liegen, auf die das importierte Projekt dann lesenden Zugriff hat) und als Inhalt des Layers sollte der Inhalt des Original-Layers (also des Layers, der in dem exportierten Projekt verwendet wurde) übernommen werden. ABER "jdbs.SCHEMA" muss in dieser neuen Layerdefinition gesetzt werden!

Nur so kann das System sicher sein, dass der beim Import ausgewählte Layer zu der richtigen Datenbank (und Schema) führt."

Mal abgesehen davon, dass man sich darüber streiten kann, ob dieses Verhalten "völlig korrekt" ist...

Wenn ich es richtig verstehe, müsste ich einen neuen Default-Layer anlegen, der genauso heisst, wie das Schema, dass der ursprüngliche DBA-Layer erzeugt hat und außerdem mit diesem Schema verbunden ist. Korrekt?

Dies habe ich versucht, in dem ich einen neuen Layer erzeugt habe und das Parameter jdbc.SCHEMA entsprechend gesetzt habe. Ein "Test Connection" liefert jedoch einen Fehler: "Schema '...' does not exist." Der Name stimmt. Wir verwenden MS-SQL Server 2008 R2. Gibt es bei dieser DB bekannte Besonderheiten?

[rrichter]

entspricht in Ihrem Fall der Name des Schemas dem DatabaseName?

[rrichter]

könnten Sie mir die Layer-Definition (natürlich ohne Zugangsdaten) einmal zusenden inkl. der genauen Fehlermeldung?

Vielen Dank,

Raphael Richter.

[oliver]

Hallo Herr Richter,

wir sind hier jetzt mit dem obigen Hinweis bereits weiter gekommen. Aufgefallen ist mir noch folgendes:

• Der neue Default Layer muss entgegen dem obigen Kommentar nicht wie das DB-Schema heißen. Er lässt sich beim Import auch verwenden, wenn er anders heißt.
• Wenn man die Paketverwaltung benutzt, um das globale FS-Schema inkl. Tabellenvorlagen an die Slaves auszurollen, muss man nach dem Projektimport auch den ursprünglichen DB-Layer wieder in das importierte Projekt einbinden (kein Schema sync, schreibgeschützt)
  • Bei der ersten Aktualisierung des Template-Paketes wird (anscheinend) die Verknüpfung des FS-Schemas mit dem ursprünglichen Layer wiederhergestellt.
  • Nach der ersten Aktualisierung kann der neue Default Layer wieder aus dem Projekt entfernt werden, er scheint nicht mehr benötigt zu werden.

Viele Grüße,

Tilman Linden

[rrichter]

Hallo Herr Linden,

das freut mich. Die Beobachtungen sind soweit korrekt.

Wenn der ursprüngliche Layer ein Standard-Layer ist, sollte das auch ohne den Umweg über den Default-Layer gehen sondern direkt darauf gemappt werden können.

Viele Grüße,
Raphael Richter.