Wie migriere ich das Design Pattern Framework 4.5 auf Visual Studio 2017

Über das Design Pattern Framework haben wir bereits das eine oder andere Mal berichtet. Darüber hinaus habe ich in der Vergangenheit nach Rücksprache mit den coolen Jungs der Data & Objects Factory Lizenzen für das Framework auf Entwicklerkonferenzen verlost. Die waren sehr gefragt. Kein Wunder… oder wisst ihr etwa, wie man in einer Windows Forms Anwendung das MVP Pattern einsetzt?

Der Haken: Es gibt leider noch immer keine neue Version vom Design Pattern Framework und die letzte verfügbare ist für das Visual Studio 2012 entwickelt worden. Das ist an sich nicht schlimm, doch unglücklicherweise denken sich Hersteller von z.B. Entwicklungsumgebungen und Frameworks mit neuen Versionen seltsamerweise oft auch noch gleich neue Features aus, verwerfen alte und überdenken einiges gar komplett neu. Und so kommt, was kommen muss: Das Design Pattern Framework 4.5 funktioniert nicht mal eben so mit dem neuen Visual Studio.

Klick auf MEHR… für eine Auflistung von nur 5 Schritten, um die Design Pattern Framework Solution  “Patterns in Action” auf Visual Studio 2017 zu migrieren (zum Schluss gibt es noch einen Bonus).

More...

Bugfix: Glossar Beschreibung im OIA anzeigen

Mit diesem Artikel folgt ein weiteres Deep Dive in die Welt des OIA (Oracle Identity Analytics). Dieses Mal vor dem Hintergrund eines Bugs, dessen Lösung im Folgenden beschrieben wird.

Im letzten Artikel haben wir gezeigt, wie eine Zertifizierung auf der Grundlage lokaler Konten konfiguriert und durchgeführt werden kann. Da es dabei erforderlich ist, Primärschlüssel zusammenzusetzen, entstehen für die Attribute relativ lange Namen. Das macht die Darstellung für den Zertifizierer unübersichtlich.

Zu sehen war deswegen in dem Artikel, wie beispielsweise die Gruppenmitgliedschaft zwar als Kombination zwischen Server, Account und Gruppe importiert wurde (“SRV01 > A000002 > Users”), die Anzeige sich aber während der Zertifizierung auf die Darstellung der Gruppe beschränkt:

image

 

Klickt nun der Zertifizierer auf die Gruppe, können Glossarinformationen angezeigt werden, die in diesem Beispiel im Feld Description eine Beschreibung des Servers mitführt. Das kann dem Zertifizierer dabei helfen, den Kontext besser zu verstehen. Damit das funktioniert, müssen ressourcenabhängig Glossarinformationen importiert werden.

Import Glossary

Datei: …\import\schema\Betriebssystem_glossary.rbx

# @iam:namespace name="Betriebssystem" shortName="OPS"
attributeName,atributeValueValue,endpointName,definition,shortDescription

Datei: …\import\in\Betriebssystem_01_glossary.csv

"groups","SRV01 > D000001 > Users","Windows","Users","Zentraler Entwicklungsserver"
"groups","SRV01 > D000001 > Developers","Windows","Developers","Zentraler Entwicklungsserver"
"groups","SRV01 > A000002 > Administrators","Windows","Administrators","Zentraler Entwicklungsserver"
"groups","SRV01 > A000002 > Users","Windows","Users","Zentraler Entwicklungsserver"

Das Ergebnis des Imports kann nun im Identity Warehouse im Bereich Data Management der jeweiligen Ressource eingesehen werden:

image

Wenn der Zertifizierer während der Zertifizierung nun wie oben dargestellt auf einen Glossareintrag klickt, erhält er aber folgendes Popup:
image

 

Was fehlt, ist die Description. Und der Grund hierfür ist der oben erwähnte Bug in OIA.

Analyse

Bei der Analyse des Datenstroms zwischen Server und Browser mit Hilfe der Internet Explorer Developer Toolbar hat sich gezeigt, dass die Daten für das Popup über den Service dwrIDCService mit der Methode loadBatchUserAccounts gezogen werden. Der Blick in den Quellcode hat zutage gefördert, dass am Ende die Abfrage getIDCAccountAttributesFlatByUser ursächlich für das Problem verantwortlich ist. Da allerdings im OIA das (inzwischen abgemeldete) Produkt iBATIS zum Einsatz kommt, lässt sich die Abfrage leicht einsehen. Sie befindet sich in der Datei IDCAccount.xml im Verzeichnis …\WEB-INF\classes\com\vaau\rbacx\idc\dao\ibatis\maps.

Zunächst wird in der Abfrage ein Defaultdatensatz erzeugt:

<select id="getIDCAccountAttributesFlatByUser" resultMap="account-attribute-wrapper">
  select
  null as attribute_value_id,
  null as attribute_id,
  null as attribute_value,
  null as glossary_def,
  null as short_description,
  null as attribute_name,
  ,
  

 

Einige Zeilen später findet ein Union statt mit einer Abfrage, die die tatsächlichen Daten aus der Datenbank bezieht. Hier zeigt sich das Problem:

select 
   
  idc_account_attributes.short_description as short_description, 
    
from 
  idc_account_attributes, attributes, idc_user_acct_attrs, idc_accounts, namespaces 
  
  

 

Der Blick in die Datenbank zeigt, dass sich hier schlicht keine Daten befinden. Die Glossarinformationen wurden beim Import nämlich in die Tabelle attribute_value_metadata eingelesen.

Lösung

Die Abfrage muss angepasst werden, so dass die Tabelle attribute_value_metadata mit einbezogen wird. Dabei ist darauf zu achten, über die Where-Klausel die Verknüpfung korrekt zu definieren.

select 
   
  attribute_value_metadata.short_description as short_description, 
   
from 
  idc_account_attributes,attribute_value_metadata, attributes,  
where 
  attributes.attributekey = idc_account_attributes.attribute_id and 
  attribute_value_metadata.attribute_value_id=idc_account_attributes.iam_attr_val_id and 
  attribute_value_metadata.endpoint_id=idc_accounts.endpoint_id and 
  idc_account_attributes.id = idc_user_acct_attrs.account_attribute_id and
   
  

Das war es auch schon.

An dieser Stelle ein leider notwendiger Hinweis: Soweit wir es sagen können, hat diese Änderung keine Auswirkungen auf das restliche Produkt. Da wir den OIA aber nicht entwickelt haben, können wir dafür keine Gewährleistung übernehmen. Sollten Sie daher ebenfalls Änderungen an Ihrem System vornehmen, geschieht das auf eigene Gefahr.

Fazit

Leider zeigt sich beim OIA, dass durch den turbulenten Lebenslauf (entwickelt von vaau, übernommen von Sun, gekauft von Oracle) die eine oder andere Unstimmigkeit entstanden ist. Von außen lässt sich natürlich schwer nachvollziehen, welches Unternehmen nun ursächlich für solche Probleme verantwortlich ist. Das ist aber auch unerheblich. Wichtiger ist, dass man sie lösen kann.

Wir konnten dieses Problem durch den Einsatz verschiedener Analysewerkzeuge inkl. Einsicht in den Quellcode identifizieren und nachhaltig beheben. Da von einem Unternehmen, das den OIA zum Zweck der Zertifizierung von Benutzern, Rollen und Konten einsetzt, natürlich kaum erwartet werden kann, so tief in die Technik einzusteigen wenn etwas nicht funktioniert wie erwartet, gibt es für Kunden i.d.R. nur eine Option: Bei Oracle einen Spezialisten einkaufen.

Oder aber Sie fragen uns. :)

Wie eine Attribute-Level Remediation in OIA funktioniert…

… wissen wir leider auch nicht.

Das heißt: Eigentlich schon. Aber es ist nicht gerade so, dass die Funktion besonders sinnvoll erscheint. Doch was ist damit eigentlich gemeint?

In Oracle Identity Analytics werden Daten vereinfacht gesagt wie folgt strukturiert:

image

 

Es gibt also globale Benutzer (darunter versteht der OIA Identitäten, also reale Menschen) und darunter Accounts. Sprich: Ein Mensch kann über mehrere Accounts (z.B. Anmeldekonten) verfügen. Jedem Account können mehrere Attribute zugewiesen sein, die den Account besser beschreiben. Dabei können Attribute auch verschachtelt werden. Beispielsweise ist es so möglich, folgendes abzubilden:

Global User > Account > Group Membership > Folder Permissions

In diesem Fall kann also ein Mitarbeiter über einen Account verfügen, der Mitglied in verschiedenen Gruppen ist, wobei jede Gruppe über spezifische Verzeichnisberechtigungen in irgendwelchen Netzwerk-Shares verfügt.

Attribute-Level Remediation

Unter Remediation versteht man in der Welt des OIA die Notwendigkeit von Korrekturen, die immer dann anstehen sollten, wenn eine IST-Situation von einem SOLL abweicht. Hat ein Mitarbeiter z.B. das Unternehmen verlassen, sein Account existiert aber nach wie vor im Active Directory, müsste bei einer Identity Certification genau das herauskommen: Der Zertifizierer bekommt den Mitarbeiter vorgelegt und lehnt ihn direkt ab (disclaim). Der OIA erkennt den Unterschied und führt den Benutzer der Korrekturverfolgung zu (Remediation Tracking).

Was aber, wenn nicht der Benutzer (bzw. die Identität oder wie der OIA sagen würde: der Global User), und auch nicht in dem Sinne dessen Account, sondern stattdessen Gruppenmitgliedschaften zertifiziert werden sollen – bzw. korrigiert werden sollen, falls IST und SOLL voneinander abweichen?

Dann ließe sich das – nach offizieller Aussage – mittels der Data Owner Certification abbilden. Neben der Benutzer-, Rollen- und Ressourcenbasierenden Zertifizierung ist das die Nummer vier im Bunde:

image

 

In dieser Art der Zertifizierung ließe sich nämlich auf Ebene der Attribute arbeiten. Dazu werden einfach die gewünschten Attribute ausgewählt:

image

 

Doch nun kommt der Pferdefuß: Wie bei allen anderen Zertifizierungstypen auch muss natürlich noch die Frage beantwortet werden, wer denn nun die Zertifizierung ausführen soll. Bei einer Identitätsbasierenden Zertifizierung kann das z.B. der Manager der jeweiligen Ressource sein, oder aber der Manager der jeweiligen Abteilung.

Bei der Data Owner Zertifizierung kann entweder nur ein einziger Mitarbeiter dazu auserkoren werden, oder aber – hence the name – der jeweilige Data Owner. Ein einziger Mitarbeiter wäre in den meisten aller Fälle unsinnig. Denn der müsste dann ja die entsprechenden Attribute aller Mitarbeiter des Unternehmens zertifizieren. Und in der Annahme, dass nur Großunternehmen ein Produkt wie den OIA einsetzen, gehe ich davon aus, dass einen Mitarbeiter mit dem Thema zu beschäftigen vermutlich gegen das Arbeitsschutzgesetz verstößt (oder wird Folter hier nicht berücksichtigt?).

Data Owner

Wer ist denn nun also der Data Owner?

Die Ressourcenansicht zeigt: Jedes einzelne Attribut an jedem einzelnen Account hat einen eigenen Data Owner:

image

 

Interessanter Fact am Rande: Die Frage danach ob es Sinn ergibt oder nicht mal beiseite gestellt, lassen sich Data Owner über die OIA Oberfläche hinzufügen. Die Sache ist nur die: Man kann sie nicht wieder entfernen (nur ein Hinweis, falls es jemand versuchen sollte).

Da aber auch hier ein gewissen Mengenproblem dem Tatendrang die Motivationsgrundlage entzieht, stellt sich also eher die Frage, ob sich der Data Owner beim Importieren der Accounts setzen lässt. Einen pfiffigen BI-Experten mit Kenntnissen in der Bedienung eines modernen ETL Tools vorausgesetzt wäre das doch die Lösung. Richtig?

Falsch. Denn der Data Owner lässt sich eben nicht automatisiert importieren.

Ende der Geschichte.

Falls jemand dazu andere Informationen vorliegen hat, oder einen Weg kennt, das Problem zu lösen, freue ich mich über einen Kommentar. Anderenfalls greife ich es vielleicht noch einmal auf, sollten wir selbst dazu eine Lösung finden (mir schwebt hier die Implementierung eines benutzerdefinierten Post-AccountImport Jobs vor – ähnlich den MaintenanceJobs und einer konfigurierbaren Zuordnung zwischen Attribute-Values und Data Ownern).

Nie wieder Ärger mit NuGet!

Vielleicht hast du das auch schon erlebt, wenn du NuGet und TFS verwendest:

Das Updaten eine NuGet Pakets erzeugt völliges Chaos in der Projektmappe:

Im Projektmappen-Explorer sieht alles gut aus. Die Ansicht „Ausstehende Änderungen“ im Team Explorer zeigt ein anderes Bild: Nur ein paar Dateien sind geändert, und viele Dateien sind gelöscht, obwohl sie ebenfalls geändert sein sollten.

Durch Einchecken wird das Projekt dann defekt: Dateien werden fälschlicherweise gelöscht, obwohl sie noch in den Projekten verwendet werden, und die Builds schlagen fehl.

TL; DR: Das Problem tritt nur bei lokalen Arbeitsbereichen (Local Workspace) auf. Benutze einen Serverarbeitsbereich (Server Workspace) zum Aktualisieren von NuGet Content-Paketen (Kurzanleitung siehe Ende des Artikels).

Was ist das Problem?

Das Problem tritt nur mit NuGet Paketen auf, die Dateien in das Projekt hineinkopieren, wie z.B. JavaScript Bibliotheken, Views, etc. Ich nenne diese Pakete „Content-Pakete“. Pakete, die nur DLLs referenzieren, sind nicht betroffen.

Beim Installieren eines Content-Pakets kopiert NuGet die Content-Dateien in dein Projekt und fügt die Dateien korrekt der Versionskontrolle hinzu.

Beim Update eines Content-Paketes geht NuGet vor wie immer:

Zunächst werden das Paket und alle dazugehörigen Dateien gelöscht; auch die in das Projekt kopierten Content-Dateien und alle DLL-Referenzen zu dem Paket entfernt. Daraus ergibt sich dann eine Anzahl von „Ausstehenden Löschungen“.

Im nächsten Schritt installiert NuGet dann die neue Version vom Paket, als wäre es die Erstinstallation: Das Paket landet im Paket-Verzeichnis, DLL-Referenzen werden hinzugefügt, und die Content-Dateien werden in das Projekt kopiert und als neue Dateien der Versionskontrolle hinzugefügt.

Hier fangen die Probleme an:
Die Content-Dateien sind immer noch als „Ausstehenden Löschungen“ in deinem Workspace markiert. Wenn NuGet versucht, genau diese Dateien wieder dem Projekt hinzuzufügen, stolpert der Team Explorer: Er erlaubt nicht, eine Datei der Versionskontrolle hinzuzufügen, für die im gleichen Workspace noch eine ausstehende Löschung besteht, sondern erwartet, dass man die Löschung erst eincheckt, und anschließend die Datei als neue Datei eincheckt. Sinnvoller wäre es, wenn der Team Explorer die ausstehende Löschung automatisch in eine ausstehende Änderung umwandelt.

Daraus entsteht das nächste Problem:
NuGet scheint von dem Fehler im Team Explorer nichts mitzubekommen, und kopiert die aktualisierten Content-Dateien auf die Festplatte und fügt sie dem Projekt hinzu (und meldet keine Fehler). Deshalb sieht im Solution Explorer alles gut aus: Alle Dateien sind dort wo sie hingehören, das Projekt kompiliert. Der Team Explorer sieht das anders: In der Ansicht „Ausstehende Änderungen“ sind die ausstehenden Löschungen immer noch vorhanden. Wenn man diesen Umstand nicht bemerkt und die offenen Änderungen eincheckt ist das Projekt für Alle defekt.

Falls man das Problem noch rechtzeitig bemerkt und versucht die ausstehenden Löschungen rückgängig zu machen, hat man auch verloren: Der Team Explorer weigert sich, die Löschungen rückgängig zu machen, da dadurch bestehende Dateien überschrieben werden würden… die Dateien die NuGet beim Update versucht hat in das Projekt hinzuzufügen!

Das Chaos manuell wieder aufzuräumen, und dabei sicherzustellen, dass man auch die aktuellen Versionen der Dateien an der richtigen Stelle hat, macht keine Freude.

Lösung

Die Problemlösung ist einfach: Benutze einen Server Arbeitsbereich zum Aktualisieren von Content- Pakete;, nur die lokalen Arbeitsbereiche sind betroffen (zumindest in der aktuellen NuGet Version 2.8.60318.667). Für meine tägliche Arbeit bevorzuge ich einen lokalen Arbeitsbereich, daher benutze ich einen zweiten Arbeitsbereich zur Aktualisierung von Content-Paketen.

Anlegen eines neuen Server Arbeitsplatzes in Visual Studio

  1. Datei > Quellcodeverwaltung > Erweitert > Arbeitsbereiche > Hinzufügen > Erweitert
  2. Sprechenden Namen eingeben, z. B. “Server Arbeitsbereich für Content-Package Updates”
  3. “Server” bei “Speicherort” auswählen
  4. OK

clip_image002

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS