"normale" DB zum NAB machen

[buzzy666]

Moing,
wir haben hier eine Anwendung A, die periodisch ein NAB mit Datensätzen (=Kunden) befüllt, bzw. diese updated. Nachdem dieses NAB sonst keinerlei Funktion hat, außer dass sich die dort angelegten User an einer anderen Anwendung B anmelden können haben wir uns gedacht, dass wir das NAB killen und die Anwendung A mit NAB-Fähigkeiten ausstatten.
Nun die Frage: ist das mit dem Hinzufügen einiger NAB-spezifischer Design-Elemente getan, oder ist das nicht so einfach...?

Danke & Gruß,
Buzzy

[buzzy666]

Nachtrag: AFAIK wird das bisherige spezielle NAB nur zur Authentifizierung von Web-Usern hergenommen...

[ascabg]

Hallo,

Mal ganz dumm gefragt.

Was ist mit den ganzen Server-Informationen?
Was ist mit den Server-Konfigurationen?
Was ist mit dem gesamten Mail-Routing?
Mailverteiler?
MailIn-Datenbanken?

Und da liessen sich noch einige Punkte mehr nachfragen.


Andreas

[Glombi]

Da wirds wohl einfacher sein, die Elemente aus der Anwendung in das NAB einzufügen als umgekehrt.

Ich persönlich würde das aber getrennt halten: Applikation und zusätzliches Dom Dir. Letzteres basiert dann auf der Standardschablone von IBM. Und da dreht
IBM gerne mal dran rum. Und das müsstet Ihr dann immer nachziehen...

Andreas

[buzzy666]

Hi,

@ascabg: ich habe von der ganzen administrativen Seite keine Ahnung (wie man vielleicht merkt *g*)
Das war so der naive Entwickler-Wunsch: Kopiere Bibliothek A sowie Agent B und Ansicht C in die Datenbank und fertig ;-)

@Glombi: Ja eine Trennung ist auf jeden Fall besser, aber ebendiese ist ja im Moment der Stein des Anstoßes, weil wir >2000 User, die in der Datenbank A verwaltet werden in eine Gruppe in dem NAB syncen müssen, nur damit sie sich anmelden können. Und wenn der Sync halt mal nicht klappt muss man manuell nacharbeiten. Das wollen wir halt umgehen mit der "Lösung".

Na dann werden wir wohl weiter-hirnen - das mit dem Zusammenlegen der Anwendnung und des (kompletten) NAB erscheint mir auch sehr hässlich.

Danke & Gruß
Buzzy

[ascabg]

Mal ganz einfach.

Wenn ich mich noch richtig erinnere, dann kann man dieses Szenario doch relativ einfach
mit einer DA abbilden. (DA = Directory Assistance)


Andreas

[Tode]

Prinzipiell kann jede Datenbank als Adressbuch verwendet werden wenn:

- die Standard- Feldnamen verwendet wurden (Firstname, LastName, MailAddress, InternetAddress, FullName)
- Alle Lookup- ansichten vorhanden und sauber gefüllt sind:
   - ($ServerLookup) : Kann auch leer sein, muss aber vorhanden sein
   - ($Users) : Hier zieht er sich die Personeninformationen raus.
   - ($NamesFieldLookup): Die $Users wird nur durchsucht, wenn die $NamesFieldLookup vorhanden ist...

   - ($PeopleGroupsXXXXX)

- Ein Profil- Dokument "DirectoryProfile" mit einem Feld "Domain"...

Aber empfehlen würde ich das trotzdem nicht aus bereits genannten Gründen, auch weil es dazu führen kann ,das ganz andere Funktionalitäten nicht mehr gehen (z.B. die AutoPopulated Groups gehen nicht, wenn nur ein Adressbuch der DA eine falsche Schablone hat)

[koehlerbv]

... weil wir >2000 User, die in der Datenbank A verwaltet werden in eine Gruppe in dem NAB syncen müssen, nur damit sie sich anmelden können.

Du packst tatsächlich 2.000 Strings in eine Gruppe? Die fliegt Dir doch um die Ohren wegen der max. Grösse von Textfeldern ...

Bernhard

[buzzy666]

Du packst tatsächlich 2.000 Strings in eine Gruppe? Die fliegt Dir doch um die Ohren wegen der max. Grösse von Textfeldern ...
Bernhard

Das ist einer der Gründe, warum wir das umbauen wollen ;-)

[Peter Klett]

Ihr könntet mit Untergruppen arbeiten. Angenommen, Ihr schreibt maximal 100 Einträge in eine Gruppe, dann habt Ihr Platz für 10.000 Benutzer (100 Untergruppen á 100 User), diese 100 Untergruppen kommen dann in die Gruppe, die Ihr heute nutzt.

Da braucht Ihr nur Euren Sync-Agenten anzupassen ...