Ax & SQL Server 2005

Hallo Zusammen,

Ich habe schon ausgiebig das Forum durchforstet und hoffe dass Eure gebalte Kompetenz auch mir helfen kann ;)

Die Daten aus unserem ERP System (MS Dynamics AX 4.0.63..) liegen auf einem SQL Server 2005. Da der SQL Server mit den Reporting Services ein mächtiges Tool in Sachen Reporting beherbergt, würde wir dieses auch sehr gerne für sämmtliche Berichte auf Basis der AX-Daten verwenden.

Nun habe ich zwei spezielle Fragen diesbezüglich:

1: In Axapta wird ein umfassendes Rollen-& Berechtigungskonzept verwaltet (Was darf ein Benutzer sehen was nicht -> bis auf Feldebene). Natürlich sollte dieses Berechtigungskonzept auch irgendwie für die Berichte gelten. Dass soll heißen, bloß weil ein Endandwender gerade einen Bericht erstelltn, soll er nicht mehr Daten sehen als wie wenn er im Ax arbeiten würde. Gibt es eine Möglichkeit das sich dies irgendwie realisieren lässt?

2: Tabellenverknüpfungen: Sobald ich über Visual Studio->Modell-Designer meine Tabellen für die Datenquellen zusammensuche, muss ich diese noch teils händisch "nachverknüpfen" und uU korrigieren, da die zusammenhänge nur in "AX-Ebene" hinterlegt sind (XRefTableRelation). Gibt es irgendwie eine möglichkeit, diese auch auf "SQL-Ebene" zu hinterlegen, sodass die Tabellen automatisch verknüpft werden?

Ich hoffe ich bin mit meinem Anliegen auch am richtigen Platz ;) !?

Über viele Antworten & Tips würde ich mich freuen.

Beste Grüße

Hi,

1: ...Natürlich sollte dieses Berechtigungskonzept auch irgendwie für die Berichte gelten. Dass soll heißen, bloß weil ein Endandwender gerade einen Bericht erstelltn, soll er nicht mehr Daten sehen als wie wenn er im Ax arbeiten würde. Gibt es eine Möglichkeit das sich dies irgendwie realisieren lässt?

Das Berechtigungskonzept von Dynamics AX 4.0 kann leider nicht 1:1 auf SSRS übertragen werden. Generell kann man sagen, dass entsprechende Berechtigungen mehr oder minder "doppel" gepflegt werden müssen.
So ist es auch im MSDN zu lesen:

... Be aware that Reporting Services roles and security are not managed by the Microsoft Dynamics AX installation program or application. Reporting Services roles and security must be managed by an administrator through Microsoft SQL Server 2005 Reporting Services Report Manager...

2: Tabellenverknüpfungen: Sobald ich über Visual Studio->Modell-Designer meine Tabellen für die Datenquellen zusammensuche, muss ich diese noch teils händisch "nachverknüpfen" und uU korrigieren, da die zusammenhänge nur in "AX-Ebene" hinterlegt sind (XRefTableRelation).

Das ist soweit richttg. Für Dynamics AX 4.0 werden auf Datenbankebene keine Relationen zwischen den Tabellen "verwaltet".

Allerdings gilt es hierbei eine entscheidende Frage zu klären. Wer erstellt die Reports?

1. Entwickler:
Wenn die Reports durch einen Entwickler erstellt werden, sollte dieser keine Problem haben, die Relationen aus AX in VisualStudio (Modell-Designer) zu übertragen.

2. Anwender:
Für Anwender gibt es eine speziellen Report-Designer (wird mit den SSRS ausgeliefert). Für diesen können entsprechende "Datenmodelle" aus Dynamics AX generiert werden.
Der Report-Designer liefert zwar nicht alle Features, welche in Visual Studio vorhanden sind, aber die Funktionen sollten für einen Anwender ausreichend sein.

Bitte hierzu einfach mal die folgenden Links ansehen.

Ad hoc reports
Set up and configure ad hoc reporting
Ad hoc reporting security

Hallo,

Danke für die Antwort.
Zu dem Thema Berechtigungen würde ich gerne noch etwas nachhaken:
Punkt 7 in der MSDN:

http://msdn.microsoft.com/en-us/library/aa569742(AX.10).aspx
- ...
- Data security is automatically enforced according to Microsoft Dynamics AX user-group permissions. If a user does not have permission to view specific data, the report returns zeros or null values.
- ...

Wenn ich die MSDN richtig verstanden habe, würde das Berechtigungskonzept auf Berichtsgenerator-Ebene wieder greifen !?
Dass würde heißen, der Entwickler stellt dem Anwender das "Datenmodell" für seinen Bericht zusammen, und dieser kann nun den Bericht im Berichtsgenerator erstellen, sieht jedoch nur die Daten, die für ihn zulässig sind. - Oder falsch interpretiert?
Wie ist das mit erstellten Berichten? Werden mir nur die Daten angezeigt, für die ich eine Berechtigung habe oder wird Pauschal alles angezeigt?

Über eine weitere Antwort würde ich mich freuen.

Hi,

soweit solltest du das richtig verstanden haben. Steht ja auch genau so im MSDN.
Allerdings bitte immer daran denken, dass es sich hierbei nur um die Ad-Hoc Reports dreht.

Dies gilt nicht für Bereichte, welche ein Entwickler (nur) mit Visual Studio erstellt hat.

Wie ist das mit erstellten Berichten? Werden mir nur die Daten angezeigt, für die ich eine Berechtigung habe oder wird Pauschal alles angezeigt?

Die Frage verstehe ich nicht ganz. Meinst du die vorgenerierte Berichte die z.B. nächtlich generiert werden oder wie ist deine Farge zu verstehen?

Hi,

Mit "erstellten Berichten" meine ich die Berichte die vom Entwickler in Studio erstellt wurden. -> Daten dieser Berichte werden von allen vollständig gesehen; ohne Berücksichtigung des Berechtigungskonzeptes !?
Im Gegensatz dazu: Ad-Hoc Berichte:
Entwickler stellt dem Anwender ein Datenmodell (zuvor in Studio erstellt) zur Verfügung. Anwender A kann nun über den Berichtsgenerator auf Basis des Datenmodells seinen Report erstellen. -> Greift hier das Berechtigungskonzept ?! ( z.B. Anwender A darf keine Artikel mit A* sehen -> sieht er desshalb auch keine Artikel mit A im Bericht ?? ) Was ist wenn Anwender A seinen Bericht nun in einem öffentlichen Ordner auf dem ReportSever speichert, wo Anwender B auch zugriff hat (Anwender B sieht keine Artikel mit B*). Was würde Anwender B sehen, wenn er den Bericht von Anwender A öffnet?

Noch eine andere Sache: Ich kann in der Entwicklungsumgebung AOT -> Data Dictionary Perspectives anlegen. Wenn ich diese dann aktualisiere (dauert enorm lange!?!) kann ich sie als "Datenmodell" verwenden...Wo ist der Unterschied zum erstellten Modell aus Visual Studio? Und kann ich diese auch einzeln aktualisieren?

Viele Grüße,
Sebastian Kircher

Hi,

Mit "erstellten Berichten" meine ich die Berichte die vom Entwickler in Studio erstellt wurden. -> Daten dieser Berichte werden von allen vollständig gesehen; ohne Berücksichtigung des Berechtigungskonzeptes !?

Ja, das ist so richtig. Für Berichte, welche "nur" mit Visual Studio erstellt werden (Datenmodell in VS erstellt) greift das AX Berechtigungskonzept nicht.
Hier greift "nur" die in den Reporting Services eigenbaute Berechtigung.

Im Gegensatz dazu: Ad-Hoc Berichte:
Entwickler stellt dem Anwender ein Datenmodell (zuvor in Studio erstellt) zur Verfügung. Anwender A kann nun über den Berichtsgenerator auf Basis des Datenmodells seinen Report erstellen. -> Greift hier das Berechtigungskonzept ?! ( z.B. Anwender A darf keine Artikel mit A* sehen -> sieht er desshalb auch keine Artikel mit A im Bericht ?? )

Soweit ich weis, greift die Record-Level-Security nicht für SQl Server Reports. Hier muss, wenn möglich, eine Lösung in den Berechtigungen des Report Servers eingestellt/gefunden werden.
Für Ad-Hoc Berichte, Datenmodel aus Dynamics AX erstellt (Persepktives), greift glaube ich nur das "allgemeine" AX Berechtigungskonzept ohne RLS.

Da das Thema durchaus etwas komplizierter ist, würde ich empfehlen, mal einzelne Szenarien in einer Testumgebung auszuprobieren.
Leider ist gerade das Thema Berechtigungssteuerung mit AX 4.0 und SSRS nicht ganz ohne und auch nicht umbedingt elegant gelößt.

Viele Berechtigungseinstellungen müssen leider auf Ebene der SSRS Berechtigungen neu gepflegt werden.