De eerste stap is het importeren van de nds-gegevens.[2]
Bekijk de inhoud van de tabel NDSEXPORT
Start ndsimport op.
Bekijk de inhoud van de tabel NDSEXPORT nog eens.
In de demo wordt het bestand importdata/ndscur.data ingelezen. Dat dit zo is, en hoe de regels in dit bestand nds-users voorstellen is vastgelegd in de java class SampleOrg. In de praktijk zullen de gegevens meestal uitgebreider zijn en via jdbc worden ingelezen. Voor de demo is gekozen voor een tekst-bestand. (weer een properties-bestand)
In ndscur.data zijn een een paar test- en systeemgebruikers vermeld. Het is niet mogelijk om met een geheel lege nds te beginnen. CUG maakt namelijk geen containers aan. Alleen containers die voorkomen in NDSEXPORT worden als geldig beschouwd.
Bovendien maakt CUG alleen gebruikers aan in de in SysGroepContainer vermelde containers.
In de oorspronkelijke ndscur.data (zie importdata/ndscur.in) zijn ook gebruikers in andere containers opgenomen om te demonstreren dat CUG:
alle bestaande gebruikersnamen in acht neemt bij het aanmaken van een nieuwe gebruikersnaam
geen gebruikers aanmaakt in containers die niet worden vermeld in SysGroepContainer
Alles alles goed is verschijnt de volgende of vergelijkbare output:
Figuur 3.2. Output ndsimport
0 [main] INFO cug - CUG instellingen uit: cugprogram.ini 50 [main] INFO cug - DataSource import: _not used_50 [main] INFO cug - DataSource doel: cug_sample
110 [main] INFO cug - CugResources; huidige CugOrg class: Cug sample Organization 110 [main] INFO cug.Main - Verwerken nds import 270 [main] INFO cug.Main - import bevat 7 nds users;
270 [main] INFO cug.Main - met 0 verschillende sleutels (PERSONID)
270 [main] INFO cug.Main - en 3 verschillende login namen
Deleted table: cug_sample.NDSEXPORT
84 items added to: cug_sample.NDSEXPORT 2080 [main] INFO cug.Main - Einde updaten nds export 2080 [main] INFO cug.Main - run in ongeveer: 2 seconde
| | De import wordt hier niet gedaan vanaf een jdbc databron. (De begin- en eind-underscore wijzen op een CUG defaultwaarde.) |
| | Resultaat wordt weggezet op jdbc databron 'cug_sample' |
| | Er worden 7 users herkend in de import. |
| | Die hebben geen van allen een nummer uit het administratieve systeem. |
| | Deze 7 users hebben 3 verschillende userid's; in de database kun je zien dat dat 'test' 'backup' en 'systemadmin' zijn |
| | Merk op dat er ook regels worden gelogd met een ander formaat (zonder milliseconde sinds start) |
Bij elk gebruik van CUG wordt dergelijke logging gedaan. Het formaat waarin dit gebeurt, wat wel en wat niet gelogd wordt, of er ook naar een bestand gelogd wordt etc. is in te stellen door log4j.properties aan te passen (zie www.apache.org voor details). Sommige meldingen worden nog rechtstreeks naar de console gedaan.
[2] Misschien is het beter als het importeren van de nds-gegevens de tweede stap zou zijn. Theoretisch gezien is het gunstig om het verschil in tijdstip van maken van de nds-import en aanmaken van gebruikers (verwerken van het hoofd create-rapport) zo klein mogelijk te laten zijn. Het is immers mogelijk dat een ander programma of een beheerder een gebruiker toevoegt, waardoor het mogelijk is dat CUG een niet-unieke userid als geldig gaat beschouwen voor een create-user.