[.NET] Loggen vanuit een CRM plugin - waarnaartoe?

[MrBucket]

Ik ben bezig met het maken van een plugin voor Microsoft CRM 4.0 die alle mutaties op de gegevens synchroniseert met een andere applicatie. Het is de bedoeling dat elke synchronisatie-operatie gelogd wordt naar een log-database, zodat er precies nagegaan kan worden of er operaties mislukt zijn, en zo ja, welke gegevens niet gesynchroniseerd konden worden.

Nu kan het zo zijn dat, om wat voor reden dan ook, de log-database niet bereikbaar is (database down, verkeerde connectionstring of verkeerde credentials) of dat een insert op deze logdatabase mislukt (database constraint, of door locking).

Hiervoor wil ik eigenlijk een fallback-mechanisme hebben waar ik zowel de fout die optrad tijdens het bijwerken van de log-database, alsmede de waardes die eigenlijk naar de log-database gelogd hadden moeten worden, naar toe kan schrijven. Alleen, waar moet ik dan naar toe schrijven?

Mijn eerste gedachte was een simpel tekstbestandje ergens op de server, maar afhankelijk van de context waarin de plugin draait, zou het kunnen zijn dat deze geen rechten heeft om een tekstbestand aan te maken of te vullen. En hoe kom je er dan ooit achter welke user je rechten had moeten geven?

Met andere woorden, ik ben bang voor het volgende:
-> Plugin wordt aangeroepen, en probeert deze aanroep in de logging database te schrijven.
-> Log database kan niet bijgewerkt worden, dus schrijf het verhaal naar een tekstbestand.
-> User waaronder de plugin draait heeft geen rechten om tekstbestand te wijzigen
-> En nu?

Het niet mogen schrijven naar een tekstbestand is imo een configuratie-issue, als de rechten eenmaal goed ingesteld zijn zou je hier geen omkijken naar moeten hebben. Dus wanneer ook dit niet lukt (dit zal met name na een nieuwe deployment het geval kunnen zijn), dan maar een messagebox tonen?

Wie heeft er betere ideeen?

[RobIII]

Je kunt natuurlijk ook alles in een 'transactie' mikken en pas alles committen als de insert op de log db goed is gegaan naast de wijziging in je CRM. Als alternatief kun je natuurlijk ook eerst gewoon loggen en als dat lukt de wijziging in het CRM pas doorvoeren, maar daarmee draai je het probleem om denk ik. Ik weet verder niet echt hoe het zit met MSCRM maar kun je die plugin dan niet in een bepaalde context draaien naast de huidige gebruiker? En loggen naar (bijv.) het (lokale) eventlog kan bij mijn weten altijd wel.
Maar ben je dan echt zo bang dat de DB 'weg' is? Dat zou namelijk in eerste instantie al helemaal niet mogen gebeuren.

[MrBucket]

RobIII schreef op zondag 23 maart 2008 @ 15:32:
Je kunt natuurlijk ook alles in een 'transactie' mikken en pas alles committen als de insert op de log db goed is gegaan naast de wijziging in je CRM. Als alternatief kun je natuurlijk ook eerst gewoon loggen en als dat lukt de wijziging in het CRM pas doorvoeren, maar daarmee draai je het probleem om denk ik.

Het is idd niet de bedoeling dat de update mislukt omdat het loggen niet kan

Ik weet verder niet echt hoe het zit met MSCRM maar kun je die plugin dan niet in een bepaalde context draaien naast de huidige gebruiker? En loggen naar (bijv.) het (lokale) eventlog kan bij mijn weten altijd wel.

Nou, dat valt nog vies tegen. Om het System.Diagnostics.EventLog te gebruiken moet je FullTrust permissies hebben. Als je applicatie bijvoorbeeld onder LocalIntranet valt, mag je niet naar het eventlog schrijven...

Maar ben je dan echt zo bang dat de DB 'weg' is? Dat zou namelijk in eerste instantie al helemaal niet mogen gebeuren.

In principe niet nee. Maar wanneer je een complexere manier van loggen gebruikt (wat een database naar mijn idee is), dan is de kans groter dat er iets misgaat. Hetzij door een verkeerde configuratie, hetzij door 'iets' op de database. En dan wil ik wel kunnen zien welke informatie niet in de log-database terecht is gekomen, en wat de reden was dat ik niet kon loggen.

Dus vandaar dat ik als terugvalmechanisme ook een simpele vorm van logging beschikbaar wil hebben.

[ Voor 4% gewijzigd door MrBucket op 23-03-2008 15:57 ]

[Razr]

Heb je geen mailserver beschikbaar? De server hoeft geeneens in je intranet te hangen en je kunt gewoon credentials opgeven bij het connecten. Dan kun je gewoon een mailtje met de foutmelding en evt. nog wat andere gegevens naar jezelf mailen (of naar iemand anders uiteraard).

[Haan]

MrBucket schreef op zondag 23 maart 2008 @ 14:18:
Met andere woorden, ik ben bang voor het volgende:
-> Plugin wordt aangeroepen, en probeert deze aanroep in de logging database te schrijven.
-> Log database kan niet bijgewerkt worden, dus schrijf het verhaal naar een tekstbestand.
-> User waaronder de plugin draait heeft geen rechten om tekstbestand te wijzigen
-> En nu?

De user die toevallig de plugin triggered zou helemaal niet relevant moeten zijn. De plugin draait op je server en vanuit de code in je plugin zou je prima een log bestand moeten kunnen schrijven zonder problemen met rechten, en anders zou je die wel toe kunnen kennen ( ) zodat het wel werkt.

[MrBucket]

Haan schreef op maandag 24 maart 2008 @ 13:16:
[...]

De user die toevallig de plugin triggered zou helemaal niet relevant moeten zijn. De plugin draait op je server en vanuit de code in je plugin zou je prima een log bestand moeten kunnen schrijven zonder problemen met rechten, en anders zou je die wel toe kunnen kennen ( ) zodat het wel werkt.

Dat klopt, dat zou niet relevant moeten zijn. Maar uit newsgroup posts als deze
leid ik af dat er toch het een en ander achter de schermen gebeurt m.b.t. user accounts. En om het hele ge-emmer voor te zijn wil ik in ieder geval af kunnen leiden waarom er ook naar het tekstbestand niet gelogd kan worden.

De oplossing is nu trouwens als volgt geworden:

1. In eerste instantie wordt een actie naar de logdatabase geschreven
2. Als dit niet kan, dan wordt er naar een fallback log (tekstbestand) gelogd
3. Als ook dit misgaat, wordt er een MessageBox op de server getoond met de reden waarom er niet gelogd kan worden, en onder welk account het loggen is geprobeerd.

Bij de eerste keer schrijven naar de logdatabase wordt ook geprobeerd naar de fallback log te schrijven, zodat er een messagebox getoond wordt wanneer dit niet lukt. Als het fallback log wel gebruikt kan worden, wordt dit voor een periode van 30 min. onthouden, zodat het fallback log niet onnodig volloopt.

Het tonen van een messagebox kan met een vlaggetje uitgeschakeld worden, zodat, als er zekerheid is dat met de huidige configuratie er ten alle tijde naar het fallback log gelogd kan worden, er geen (blokkerende!) messageboxes getoond worden.