Entmystifizierung des 3DEXPERIENCE-Customization-Modells

Geschrieben am 2. November 2017 von Michael Finocchiaro

(Original: https://www.linkedin.com/pulse/demystifying-3dexperience-customization-model-michael-finocchiaro/
Übersetzt von: SCHWINDT CAD/CAM-Technologie GmbH)

In den Kommentaren meines vorherigen Artikels "Entmystifizierung der 3DEXPERIENCE-Plattform" wurde ich gebeten, das unklare 3DEXPERIENCE-Sicherheitsmodell zu entmystifizieren. Nun, es ist eine heikle Bitte, aber ich werde versuchen, dies hier zu tun. Wie in meinen Artikeln üblich, werde ich den historischen Kontext, dann den Ist-Zustand und das Projekt in den Soll-Zustand bringen. Fangen wir an!

"Die Vergangenheit ist nie tot. Sie ist noch nicht mal vorbei." William Faulker

Das ist eines meiner Lieblingszitate (ich habe es zur Eröffnung meines Romans The Gramble Chronicles I: Sophies Playlist verwendet), und es ist gut geeignet, die komplexe Welt von Customization und Configuration zu verstehen. Wenn Sie das noch nicht getan haben, können Sie meinen Artikel "Demystifying Digital Dilemmas" lesen, in dem ich die Geschichte der PLM-Plattformen einschließlich der Ursprünge der 3DEXPERIENCE-Plattform skizziert habe. Wie ich dort schrieb, ist die Plattform das Ergebnis einer Fusion von VPM V6 und MatrixOne. Diese Plattformen sind schon sehr unterschiedlich:

• VPM V6 hatte einen C++-Kern und daher war das Customizing darauf ausgerichtet, Änderungen an Attributen oder Masken (Sicherheitsfilter) vorzunehmen und diese für die Verwendung in einer Rich-Client CATIA-Sitzung wieder zurück in den Kern zu kompilieren. Es war leistungsstark, aber sehr schwerfällig. Es gab eine einfachere Möglichkeit, Geschäftsprozesse in CATIA zu modifizieren (sogenannte "Business Logics" auf der KnowledgeWare-Workbench). Bis auf die Menüpunkte konnte man in der Benutzeroberfläche allerdings nur wenig verändern. Es gab auch noch eine viel größere Bibliothek namens Component Application Architecture (CAA) zum Schreiben von benutzerdefinierten Anwendungen für z.B. FEA-Analysen oder was auch immer, auf die in CATIA zugegriffen und die in einer Sitzung ausgeführt werden konnte. Im Wesentlichen könnte man das Datenmodell zwar auf einige wenige, eingeschränkte Arten erweitern und Funktionalität ausblenden, aber es war in vielen Fällen fast immer ein Neuaufbau und Neustart des Applikationsservers erforderlich. Es gab einen kleinen Java-Webserver mit einem umfangreichen C++-Kernel, der beim Start in den Java-Prozess geladen wurde. Das C++-Datenmodell war relativ knapp (nur eine Handvoll Basisklassen), jedoch ziemlich tief mit einer Ableitungsschicht nach der anderen. Die Basisklassen wurden Instance Reference Port Connection (IRPC) genannt, was immer noch der Name des Datenmodells ist, auf das man manchmal in der Dokumentation von Dassault Systèmes trifft. Es gab keine webbasierte Benutzeroberfläche.
• Um Geschäftsregeln, Sicherheit und Attribute in MatrixOne zu ändern, gab es eine Zwischensprache zwischen dem Matrix Kernel und der Structured Query Language (SQL) der Datenbank mit dem Namen Matrix Query Language (oder MQL). MQL ist eine sehr mächtige Sprache, aber mit eigentümlichen Syntax und vor allem keiner Quelltextkontrolle und keinem Rollback. Sobald eine Änderung per MQL vorgenommen wurde, war sie dauerhaft. Die Ergebnisse eines MQL-Updates sind sofort und systemweit verfügbar. Um die Benutzeroberfläche zu modifizieren, könnte man Java Server Pages (JSPs) für Web-Interface-Komponenten schreiben und/oder .properties-Dateien für die Anpassung des Servers in verschiedene Sprachen. Für eine leistungsfähigere makro-ähnliche Programmierung gab es auch Java Program Objects (JPOs), die im Wesentlichen Java-Programme waren, die in der Datenbank gespeichert und bei Bedarf zur Ausführung im Kernel kompiliert wurden, ohne eine eigenständige Java Virtual Machine zu benötigen. Daher wurde die Anpassung als Superuser mit der leistungsfähigen MQL-Befehlszeile vorgenommen (die auch von den inzwischen abgeschwächten System- und Business-Tools mit einer Galaxy-basierten Benutzeroberfläche unterstützt wird). Web-Codierer würden JSPs mit Hooks in die in der Datenbank gespeicherten JPOs schreiben und diese auf dem Webserver bereitstellen und dann die Tomcat-Instanz neu starten, um die Seiten zu kompilieren. Es gab ein Java-Frontend für das JSP- und JPO-Handling und ein C/C++-Backend für die Erstellung und Pflege der MQL-Requests. Das Datenmodell war ziemlich breit (viele, viele Basisklassen für jedes der >1000 Matrix-Objekte und -Attribute) und relativ flach (sehr wenig Unterklassen) - im Grunde wurde alles auf der Plattform entweder als ein Typ (ein Objekt) oder eine Beziehung zwischen Typen oder einem Attribut beschrieben (wobei das Wort "Typ" grob ins Französische als "entité" übersetzt wurde, man findet dieses Datenmodell manchmal in der Dassault Systemes-Dokumentation als "E/R" oder Entité/Rélation).
• In den ursprünglichen ENOVIA V6 Releases wurde die VPM V6 Infrastruktur mit der MatrixOne Foundation überlagert. Aufgrund der antagonistischen Beziehung zwischen dem produktstruktur-orientierten (schmal-tiefen) Datenmodell von VPM V6 (entwickelt für die Bearbeitung von CATIA-Daten in der Sitzung) und dem eher geschäftsprozess-orientierten MatrixOne (breit-flach) Datenmodell, ergab sich grundsätzlich ein Zwei-für-Eins-Modell. Mit anderen Worten, die Methoden der Anpassung, die ich für VPM V6 und MatrixOne beschrieben habe, blieben mehr oder weniger unverändert. Entweder ein für den CATIA (und DELMIA, um vollkommen transparent zu sein) Rich Client mit C++ und anderen kompilierbaren Tools), oder ein Web Client über JPOs und JSPs. MQL wurde etwas komplexer, da es für viele systemweite Operationen (z.B. File Collaboration Server (FCS) Management) und für traditionelle MatrixOne Datenmodelloperationen benötigt wurde und dennoch für VPM V6 Datenobjekte recht schwierig zu verwalten war.  Dies stellte viele Herausforderungen dar und kann einige der Kopfschmerzen erklären, die man in der Vergangenheit hatte.
• Bis zum Ende der V6-Ära wurde der Zugriff auf externe Systeme in Handarbeit geschrieben und basiert in erster Linie auf einem Simple Object Access Protocol (SOAP)-basierten XML-Dateiaustausch-Framework. Dies war ziemlich flexibel, erforderte aber eine umfangreiche Programmierung und verwendete relativ alte Protokolle. Spätere V6-Releases führten den XPDM-Ereignisbus ein, aber auch dies erforderte einen hohen Programmieraufwand und war im Umfang der durchführbaren Operationen eher begrenzt. Einige Unternehmen wie TechniaTranscat, T-Systems, CIDEON, CENIT, Geometric (jetzt HCL) und ProSTEP schrieben Adapter und Frameworks, die für die Plattform für den Zugriff auf Nicht-DS (also das "X" in "XPDM" bedeutet "kein DS") PDM- und CAD-Plattformen separat lizenziert wurden.

Es lebe PLM Express und TEAM! Neben RACE, OneClick Deployment Experience und Baseline...

Dassault Systèmes hat dieses Problem schnell erkannt und ein SMB-freundliches Packaging-Modell namens PLM Express entwickelt. Wir müssen uns aber auch daran erinnern, dass Dassault auch SmarTeam für die Verwaltung von CATIA V5 und SolidWorks-Daten erworben und 2009 an artizone in Israel ausgelagert hat. Der Name SmarTeam hatte einen ziemlich guten Ruf und tauchte immer noch gelegentlich in ENOVIA-Produkten auf. Einer der ersten Ansätze war das vereinfachte Datenmodell (TEAM), das für PLM Express eingeführt wurde. Die Konzepte (die ich unten zu entmystifizieren versuche) sind im Wesentlichen die gleichen in den verschiedenen Versionen seit 2010x - RACE (~V6R2012x), OneClick (~3DEXPERIENCE 2014x) und jetzt Baseline (3DEXPERIENCE 17x und weiter) - nur mit mehr "Konfiguration" und weniger "Anpassung" und besseren webbasierten Tools und, was wichtig ist, Cloud-fähigen Tools zur Personalisierung/Konfiguration.

Wenn man über die Anpassung von V6 nachdenkt, sollte man die Konzepte um den Zugriff auf

• Daten (Personen, Rollen und Organisationen (P&O) und Sicherheit),
• die der Datenmodell-Modifikation,
• die der Änderung von Business Rules und
• die der Anpassung der Benutzeroberfläche trennen.

Einige dieser Modelle blieben dieselben wie zuvor beschrieben - ein Erfordernis für Kunden, die ihre Vorgängerversionen vollständig an ihre Bedürfnisse angepasst haben und keine Möglichkeit hatten, Datenmodelle ohne Informationsverlust zu wechseln - und andere haben sich in dieser Transformation weiterentwickelt, welche mit PLM Express und TEAM begann. Als Nächstes möchte ich in diesem Artikel die Grundlagen des Zugriffsmodells erläutern und dann erklären, was Baseline in diesem Zusammenhang bedeutet.

Access Control

Es gibt vier wesentliche Konzepte, wenn es darum geht, die realen menschlichen Hierarchien in 3DEXPERIENCE zu modellieren:

• People - das sind Benutzer, die eine eindeutige ID, ein Passwort (ab 3DEXPERIENCE R2014x ein 3DPassport) und eine Rolle haben, zu einer Organisation gehören und über Produktlizenzen verfügen. Objekte, die von Benutzern auf dem System angelegt werden, gehören einem primären Benutzer (sie können aber auch "sekundäre" Besitzer haben).
• Role - im Kontext des Zugriffsmodells ist dies eine der spezifizierten Plattformrollen, die der Benutzer in einer Sitzung haben kann. Seit RACE (und damit in OneClick und Baseline) sind diese Rollen derzeit Reader, Contributor, Author oder Leader. Diese haben je eine Reihe von Rechten auf Daten und jeder Benutzer MUSS mindestens eine Rolle haben. Aber Vorsicht! Die im Marketing für die branchenspezifischen Angebote genannten Rollen ("Mechanical Designer" oder "Product Architect") sind rein packagingorientiert und haben NICHTS mit den eben genannten Zugriffsrollen zu tun. Und für die alten MatrixOne-Anhänger ("Hallo Jungs!") sind diese auch anders und inkompatibel mit den Rollen innerhalb der alten Matrix-Centrals für MQL-Zugriffsregeln - diese sind zum größten Teil veraltet und obsolet. Die Zugriffsrechte auf die Daten sind kumulativ, jeweils vom Reader zum Contributor zum Author zum Leader.
• Organization - das ist die Repräsentation einer Gruppe von Personen in einer Abteilung, einem Projektteam oder einem Unternehmen. Es kann mehrere Organizations im System geben (OEM, Lieferant, etc.) und jeder Benutzer MUSS zu einer Organization gehören. Organizations können hierarchisch organisiert werden, um reale Geschäftsstrukturen abzubilden.
• Collaborative Space - Wenn Benutzer der 3DEXPERIENCE-Plattform gemeinsam an einem gemeinsamen Satz geometrischer Dateien oder an einem Projekt arbeiten, erhalten sie einen Collaborative Space, mit dem in einer Sitzung geänderte Objekte markiert werden. Im VPM V6-Datenmodell hieß das bisher "Projekt" - in 3DEXPERIENCE R2014x wurde der Name in Collaborative Space geändert. Aus diesem Grund wurde auch die 3DEXPERIENCE User Interface Komponente, die die alte ENOVIA V6 Architektur repräsentiert, als "3DSpace" bezeichnet. Aber Vorsicht, denn der Name "Space" ist hier etwas trügerisch. Er bezieht sich NICHT auf die physische Speicherung, sondern ist vielmehr ein eindeutiges Tag auf Objekten (sie können nur zu einem primären Collaborative Space gehören) selbst. (Anmerkung: Physischer Speicher ist ein vollständig vom Datenmodell losgelöstes System, das vom File Collaboration Server (FCS) verwaltet wird. Bei Objekten, die über einen Datenspeicher verfügen, ist eines ihrer Attribute ein "Speicherort" - dies ist der physische Speicherort für das Objekt.
• Security Context - sobald wir wissen, wer in welcher Rolle und für welche Organisation arbeitet, wollen wir seine Arbeit an einer bestimmten Aufgabe oder einem Projekt oder buchstäblich einem Collaborative Space isolieren. Dieser Arbeitskontext wird als Security Context bezeichnet und besteht aus einer einzigartigen Kombination von person + role + organization, die mit einer ausgefallenen Vektor-Mathematik die Zugriffsberechnung auf Objekte in der Datenbank ermöglicht. Jedes Objekt ist mit einem Ownership Vector (Person, Organisation, Collaborative Space) versehen. Wenn ein Benutzer Zugriff auf ein Objekt beantragt, muss er Zugriff auf den Collaborative Space haben, in dem das Objekt "gespeichert" ist, und seine Rolle muss den Zugriff auf das Objekt in seinem aktuellen Lebenszykluszustand erlauben.
• Man beachte, dass es tatsächlich eine ISO-Norm für die Zugriffsverwaltung gibt, die einen Großteil der Arbeit in diesem Bereich beeinflusst hat (ISO 17799).
• Zwei weitere damit verbundene Konzepte sind die der Regeln und Richtlinien. Diese wurden auf VPM V6 und MatrixOne unterschiedlich implementiert, um bestimmten Benutzern den Zugriff auf bestimmte Objekte zu gewähren oder zu verweigern, wenn die Standardregeln nicht anwendbar waren. Die Bemühungen, die beiden Modelle zusammenzuführen, waren ein weiterer entscheidender Fortschritt der RACE/OneClick/Baseline-Initiativen, denn statt der alten Methode der Heavy Client Tools (VPM V6) oder der umständlichen, potenziell performance-killenden MQL-Ausdrücke (MatrixOne), die meisten der gebräuchlichsten Operationen konnten mit einer einfachen webbasierten Benutzeroberfläche in einer indizierbaren (zur Laufzeit schneller aufzulösenden) Weise durchgeführt werden, die als Indexable Security Keywords bezeichnet wurde, die man jetzt auf R2017x im 3DSpace Control Center Widget zusammen mit anderen Goodies wie Lifecycle-Konfiguration und Namenskonventionen sieht, um nur einige zu nennen.

Data Model - Unified Typing für alle

Das nächste Teil des Puzzles ist das Datenmodell selbst. Ich habe bereits erwähnt, dass es zwei konkurrierende Modelle (IRPC für VPM V6 und E/R für MatrixOne) gab, die einige meiner Leser bereits kennen. In 3DEXPERIENCE R2015x hat Dassault Systèmes eine Vereinfachung namens Unified Typing veröffentlicht. Die Idee war, Datenverluste zu vermeiden und die Beziehungen dieser Objekte untereinander sowie das Recht jedes einzelnen, das andere zu verändern, zu ermöglichen (Anmerkung: dies ist spezifisch für die Types, es gibt noch keine "Unified Relationship"). Es gibt einen manuellen Prozess für die Konvertierung von VPM V6-Daten in Releases vor R2015x in das neue Modell, der ziemlich einfach ist. Die mit "OneClick" und "Baseline" kompatiblen Werkzeuge können nun das Datenmodell eines beliebigen Objekts im System mit den gleichen Werkzeugen und Verhaltensweisen transparent ergänzen und erweitern. Eine große Verbesserung in der Tat.

Behaviors

Das Plattformverhalten ist mit R2017x ziemlich unverändert geblieben (und ich würde sehr wenige Änderungen in R2018x und darüber hinaus voraussagen). Das meiste wird wie oben erwähnt mit in der Datenbank gespeicherten JPOs beschrieben, die dann von anderen JPOs, von JSPs oder von benutzerdefiniertem Code aufgerufen werden. Einige einfachere Einstellungen können über das 3DSpace Control Center geändert werden.

Seit den Anfängen von V6 wurden die Begriffe Workflow und Lifecycle fast synonym verwendet (während sie auf anderen PLM-Plattformen relativ unterschiedlich waren). Einzelne Objekte durchlaufen verschiedene Lebenszyklen (Maturity) mit Signaturen, wechselnden Zugriffsregeln und ähnlichem. Um Objekte in einem erweiterten Prozess miteinander zu verbinden, kann man Routes von Punkt zu Punkt verwenden. Es gab ein veraltetes Workflow-Tool in MatrixOne, aber es wurde definitiv um V6R2012x herum entfernt. Routen und Lifecycle blieben im Wesentlichen unverändert, abgesehen von neuen webbasierten Schnittstellen zu deren Verwaltung. Was den Workflow betrifft, so kursieren einige Gerüchte - die Integration eines OpenSource-Tools in 3DEXPERIENCE oder das Recycling von 3DOrchestrate (früher bekannt als FIPER) aus der SIMULIA-Welt - aber keines davon wurde bestätigt und ich würde auch hier keine Änderungen in 3DEXPERIENCE R2018x erwarten.

User Interface: Auf dem Weg zum Web 3.0

Eine weitere wichtige Neuerung in 3DEXPERIENCE war die benutzerfreundliche Oberfläche. Wenn Sie sich erinnern, bis zu 3DEXPERIENCE R2014x, hatte jede Anwendung eine einzigartige Schnittstelle: Rich Clients für CATIA, DELMIA und SIMULIA und Web Clients, die JSPs für Web Clients nutzen. Die grundlegende Änderung in der 3DCompass-Benutzeroberfläche (siehe meinen Demystifying 3DEXPERIENCE-Artikel) war die Vereinheitlichung aller Benutzeroberflächen (UI) zu einem gemeinsamen Paradigma mit gemeinsamen UI-Komponenten (Me, Share und andere Schaltflächen in der Menüleiste oben rechts auf dem Bildschirm), einem gemeinsamen blau-grauen Farbschema und einem gemeinsamen Layout (linke Leiste für 3DCompass und Anwendungen, mittlere Leinwand für die Datenanzeige) und der oben genannten Menüleiste, unabhängig davon, ob es sich bei den Anwendungen um grafische Rich-Clients oder webbasierte Browser-Clients handelt. Das Customizing der CATIA- und DELMIA-Schnittstellen kann weiterhin teilweise über die Entwicklungsumgebung CAA2 (separat von der Plattform lizenziert) erfolgen. Für die webbasierten Clients hat sich das Paradigma jedoch komplett auf eine Web 3.0-Architektur mit HTML5/CSS3-Features und -Funktionen umgestellt. Die Hauptvorteile von HTML5 gegenüber JSPs sind Performance (keine Kompilierung erforderlich und Widgets können unabhängig voneinander aktualisiert werden) und Flexibilität (Widgets können CSS3-Stylesheets für besonders attraktive Darstellungen nutzen). Während 3DDashboard vollständig auf Widgets basiert, gibt es für ENOVIA-Anwendungen immer noch einige JSP-Seiten, die jedoch in Widgets eingebettet sind und schrittweise auslaufen. Widgets und Apps werden alle über den 3DCompass oben links auf dem Bildschirm aufgerufen.

Eine weitere wichtige Änderung ist die Implementierung von Representational State Transfer (REST) Web Services. Alle Widgets, die wir gerade besprochen haben, nutzen dieses Framework, um Zugang zu den Daten auf der Plattform zu erhalten. So einfach wie möglich formuliert, während SOAP-Schnittstellen meist eine Codierung für jeden Aufruf erfordern (enge Anbindung an die Plattform) und wenig Sicherheit bieten (d.h. keine 3DPassport-Integration), basieren REST-Schnittstellen einfach auf dem Zugriff auf einen bestimmten Universal Record Locator (URL) und der Durchführung einer "GET"- oder "PUSH"-Operation (es gibt einige andere) für den Datenaustausch und können zur Authentifizierung über 3DPassport erweitert werden. REST-Schnittstellen sind daher flexibler, weil sie offen an die 3DEXPERIENCE-Plattform gekoppelt sind und weil sie sicherer sind als SOAP-Schnittstellen. SOAP wird daher langsam veraltet und durch REST ersetzt. Bitte beachten Sie, dass die XPDM-Infrastruktur weiterhin als strategische Lösung für die Integration mit anderen PDM-Systemen existiert und vereinfacht und verbessert wird.

Finos Kristallkugel

Also, wie sieht die Zukunft für die kundenspezifische Anpassungen aus? Hier ist meine Meinung:

• Access Control: Wir erwarten, dass die Baseline weiter ausgebaut wird, um weitere Attribute und Objekte abzudecken und dass diese Funktionen gleichzeitig in der Cloud und on premise verfügbar sind. Die alten kompilierten Frameworks werden weiterhin existieren, um stark angepasste Clients zu unterstützen, aber EXTREME Vorsicht sollte geboten sein, wenn man diesen Customer-Specific Environment (CSE) Pfad geht, da er irgendwann in der Zukunft in eine Sackgasse geraten wird.
• Data Model: Es ist zu erwarten, dass die Migration auf Unified Typing in Zukunft einfacher wird und mehr Datenmodelle und Schreiboperationen über die Web-Benutzeroberfläche zugänglich sind. MQL wird weiterhin existieren, sollte aber nach Möglichkeit vermieden werden.
• Behaviors: Meine Kristallkugel hat einen toten Winkel, wenn es um den Workflow geht, also warten Sie nicht auf eine Lösung für die unmittelbare Zukunft. Nutzen Sie vielmehr die Vorteile von Routes und dem 3DSpace Control Center zur Steuerung des Objektverhaltens.
• User Interface: Ich würde vorschlagen, einige Web-Klassen auf HTML5 und CSS3 zu nehmen oder einige Bücher zu lesen (ich empfehle Beginning HTML5 und CSS3 von APress), da HTML 5 jetzt eingeführt wurde, um in 3DEXPERIENCE zu bleiben. Für REST-Webdienste empfehle ich REST in der Praxis: Hypermedia und Systemarchitektur von Jim Webber, Savas Parastatidis, Ian Robinson als Klassenbester. Mit diesen Konzepten werden Sie im Handumdrehen zum 3DEXPERIENCE Plattform-Widget-Assistenten.

Fazit

Nun, das war ein kleiner Rundgang durch meine Sichtweise, wie man die 3DEXPERIENCE-Plattform erweitern und an Ihre Bedürfnisse und Geschäftsprozesse anpassen kann. Ich habe vielleicht ein oder zwei Dinge vergessen (zögern Sie nicht, mich in den Kommentaren daran zu erinnern), aber ich hoffe, dass diese Übersicht für Sie hilfreich war.

Schließlich der obligatorische Bereich: Ich arbeitete mit (2008-2010) und für Dassault Systèmes (2010-2017) und schrieb die meisten der vorhandenen Trainingsmaterialien zu all diesen Themen. Ich habe Finocchiaro Consulting, LLC gegründet, um Kunden bei der Navigation in diesen Gewässern zu helfen, also zögern Sie nicht, mich zu kontaktieren unter Michael@Finocchiaro.Consulting.