Domino 9 und frühere Versionen > ND9: Entwicklung

Daos- Catalog: Hat jemand schonmal die $DAOSTicketList- Attachments analysiert?

(1/2) > >>

Tode:
Eine Frage, die immer wieder beim Blick in die DAOS- Verzeichnisse aufkommt: In welche Mail- Datenbank gehört denn dieses 700MB Attachment?

Leider liefert IBM ja kein Tool mit, mit dem man die Antwort auf diese Frage einfach liefern könnte.
Nun habe ich überlegt, selbst ein solches Tool zu schreiben.

Vereinfacht gesagt würde ich:

- Alle (oder gewählte) Datenbanken im Catalog oder per DBDirectory durchlaufen
- per tell daosmgr listnlo mail\Pfad.nsf -o pfad.txt alle nlos für die Datenbank in ein file schreiben
- die Informationen "aggregieren" in "nlo- Dokumente" (zwei Felder: key: nlo- Name, dbs: alle Pfade, in denen des nlo vorkommt)

Nun wird dieser Vorgang - je nach Datenbank- und Attachmentzahl etwas länger dauern...

Deshalb dachte ich: Der Domino verwaltet die Info ja auch irgendwo und habe mir mal den Daos- Catalog angeschaut.
Ich habe mir eine lokale kopie gezogen und mal die Dokumente darin analysiert. Das sind im prinzip Container mit einem einziger Item namens "$DAOSTicketList". Dieses enthält ein Objekt...

Hat sich jemand das schonmal angeschaut? Allzu kryptisch dürfte der Aufbau ja nicht sein, die Verwaltung muss ja performant sein...
Aber es scheint sich um irgendein codiertes Format zu handeln (hoffentlich nicht mit der Serverid verschlüsselt)...

Hier ein XML- Auszug aus so einem Dokument:


--- Code: ---<rawitemdata type='3'>
BgABAAAAEQCyoAIATgMAABoAAAAAAAIACAABAFr3AAA56QQAAAAAAAAAAABGOTRGNEFERjkwOUYz
NUZFRUZGNjM0MzQyREJENDcwNjlFMDQ4QjlGMDAwNEU5MzkAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAB0AAAC2AAAAGgAaAAAAAAACAAgAAQB69wAAYCEFAAAAAAAAAAAAQUY2N0UxODRGQUZE
MERBRTI5NDQwQkVBQUY5OUEyQUZCRTZGNDMyODAwMDUyMTYwAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAdAAAAtgAAABoAGgAAAAAAAgAIAAEAfvcAALaqAgAAAAAAAAAAADhEQkFDNjBGMjM2
RTkxNzY2MDU1MkU3NTQ0QzcyMzMwQTk3RUM0MDkwMDAyQUFCNgAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAHQAAALYAAAAaABoAAAAAAAIACAABAIL3AAD/awQAAAAAAAAAAABGOTUzNjI0MTI1
OUU0NjFERTZBNzYwODFCOTY3ODlFQ0Q5QzgzRUJEMDAwNDZCRkYAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAB0AAAC2AAAAGgAaAAAAAAACAAgAAQBW+AAAmcueAAAAAAAAAAAAMkUzMjkxNjE1
...
AAAAGgAaAAAAAAACAAgAAQDCKAAAx0EQAAAAAAAAAAAAQzUxNUNBREMzRjg5QjEwNjBFMEI4Qjg0
QUI4RDA0OEU5QTVBOTk2MzAwMTA0MUM3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAA
tgAAABoAGgAAAAAAAgAIAAEARioAALpMBAAAAAAAAAAAADgxNDdGMzNBMEMwNTc3QzU3RDcyQkY0
RjFEN0E3NDE4REZENURBOTUwMDA0NENCQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAA
ALYAAAAaAA==
</rawitemdata>
--- Ende Code ---

Wäre ja cool, wenn man an die Info da drin rankäme...

pram:
Die Daten sind Base64 codiert:

--- Code: ---�
����² �N��
�������
�Z÷��9é���������F94F4ADF909F35FEEFF634342DBD47069E048B9F0004E939��������������������������������¶����
�������
�z÷��`!���������AF67E184FAFD0DAE29440BEAAF99A2AFBE6F432800052160��������������������������������¶����
�������
�~÷��¶ª���������8DBAC60F236E917660552E7544C72330A97EC4090002AAB6��������������������������������¶����
�������
�‚÷��ÿk���������F9536241259E461DE6A76081B96789ECD9C83EBD00046BFF��������������������������������¶����
�������
�Vø��™Ëž���������2E3291615����
�������
�Â(��ÇA���������C515CADC3F89B1060E0B8B84AB8D048E9A5A9963001041C7��������������������������������¶����
�������
�F*��ºL���������8147F33A0C0577C57D72BF4F1D7A7418DFD5DA9500044CBA��������������������������������¶����

--- Ende Code ---
Es kommen ein paar IDs vor, evtl hilft dir das zumindest für die Suche weiter...

/edit: Encoing und Zeilenumbrüche nochmals anders gesetzt. Man erkennt eine gewisse Blockstruktur
Gruß
Roland

Tode:
Vielen Dank für die Mühe. Die Base- 64 Konvertierung passiert wahrscheinlich beim exportieren per XML. Werde mal einen Agenten schreiben, der versucht, ob man da irgendwie über "embeddedObjects" rankommt und das speichern kann...

Sieht ja so aus, als stünden da die Filenamen der Daos- Files drin. Und wahrscheinlich auch noch die UNIDs der zugehörigen Dokumente, u.u. noch die Replik- ID...

Mal schauen, ob ich mal Zeit finde, da weiter zu forschen...

eknori (retired):
evtl hilft das ... http://noteshexe.de/blog/?p=2751

Tode:
Interessant @Ulrich... Aber reduziert nicht wirklich die Dauer der Abfrage, wenn man rausfinden will, in welcher Datenbank sich ein Attachment befindet.
Natürlich erhält man im Gegenzug sogar noch genauere Informationen darüber, in welchem Dokument das Attachment ist, aber das ist -in meiner Praxis- meist nicht die Frage (kann aber interessant sein, um herauszufinden, wo genau ein "defektes" oder "fehlendes" NLO sitzt um zu entscheiden, wie gross die Anstrengungen zur Wiederherstellung sein müssen)

Navigation

[0] Themen-Index

[#] Nächste Seite