CacheAdminACommon_trunk2010

Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT] NotSupportedException rechtstreeks kunnen oproepen

- classmethod Throw toegevoegd (=override van basis) : parameters van %New overgenomen

[ICT-2302][rvJWI] Computernaam bij VPN-verbinding kan niet geresolved worden (Reflection Admin)

- method CheckAndFixUnresolvedComputerNaamBijVpnConnectie() aangepast : domein .vanhoecke.be) toevoegen indien nodig, want anders werkt de TerminalNavigatieTaak niet.

[ICT-2302][rvJWI] Computernaam bij VPN-verbinding kan niet geresolved worden (Reflection Admin)

- method CheckAndFixUnresolvedComputerNaamBijVpnConnectie() toegevoegd. Deze maakt gebruik van de nieuwe functionaliteit ShellExecute (VBA-module) "GETCOMPUTERNAME" --> Update van Reflection Admin nodig.

    • -0
    • +20
    /TECH/Context/RuntimeContext.cls.xml
[ICT-2259] [rvPVR] Interface klanten van AX naar Admin uitbreiden filter voor rare tekens
[ICT-2259] [rvPVR] Interface klanten van AX naar Admin uitbreiden filter voor rare tekens
[ICT-2259] [rvPVR] Interface klanten van AX naar Admin uitbreiden filter voor rare tekens

- Verwijderen overbodige methode 'VervangNietPrintbaarKarakterDoorAnderKarakter' met bijhorende unittesten

[ICT] ResultSetWriter (gekopieerd van zTryout.CSC)

Laatste aanpassingen aan de code van CSC :

- classmethod WriteFromClassQuery() toegevoegd, gemakkelijk om rechtstreeks op te roepen voor een Class Query

- functionaliteit toegevoegd voor Optimized Column Width, veel handiger dan voorheen :-D

    • -0
    • +109
    /Tools/ResultSetWriter.cls.xml
[Bugfix] - indien pad naar diff file spaties bevat liep het fout in de url -> urlescape lost het op.
[ICT-2168] ICT: Persistente data: alerts op snel groeiende globals

- Toevoegen van logging

    • -0
    • +3
    /Tools/GlobalSizeMonitor/Analyser.cls.xml
[ICT-2178][rvPVR] MFW: Json-request van Caché naar .NET : specifiek basis-object i.p.v. TECH.RegisteredObject...
[ICT-2178][rvPVR] MFW: Json-request van Caché naar .NET : specifiek basis-object i.p.v. TECH.RegisteredObject...
[ICT-2178][rvPVR] MFW: Json-request van Caché naar .NET : specifiek basis-object i.p.v. TECH.RegisteredObject

- basis-objecten in TECH.JSON package aangemaakt

    • -0
    • +15
    /TECH/JSON/ObjectParsedFromJson.cls.xml
    • -0
    • +9
    /TECH/JSON/RegisteredObject.cls.xml
Ok top, bedankt!!

Ok top, bedankt!!

inderdaad. T eerste deel was het belangrijkste om te begrijpen : code afzonderen (in dit geval via composition) om enerzijds de basisklasse WS.WebService niet telkens te belasten, en anderzijds om ...

inderdaad. T eerste deel was het belangrijkste om te begrijpen : code afzonderen (in dit geval via composition) om enerzijds de basisklasse WS.WebService niet telkens te belasten, en anderzijds om de complexere logica om te loggen los te trekken van de klasse zelf.

Dat je de rest niet meteen kan volgen, is geen probleem hoor. Is te begrijpen, want is idd complexere logica.
Om je toch een beetje wegwijs te maken:
de complexiteit was/is : hoe geraak ik aan de opgeroepen WebMethod naam? Want deze willen we loggen. Er zijn verschillende gebruikers die een WebService van Caché oproepen : SoapUI, Vhisie4, AX, Fop DocBase, een andere Caché-server, ...
Onlangs is er een nieuwe gebruiker om aan dit lijstje toe te voegen : de eCon-configurator. Deze gebruikt (nog) een andere manier om WS request naar Caché te sturen. Deze request heb ik geanalyseerd, en op basis daarvan, vond ik in de structuur dat de webmethod vervat zat in de property MsgClass. En in de meeste gevallen lijkt dit zelfs de beste manier om de juiste webMethod naam te bepalen.
Tot zover de uitleg voor vandaag

Ja, oude gewoonte om $G() te schrijven. Kzal het aanpassen. Reden : in dit geval hou ik rekening met andere scenario's waarbij de nieuwe parameter nog niet wordt doorgegeven. Begrijp dus als : om ...

Ja, oude gewoonte om $G() te schrijven. Kzal het aanpassen.

Reden :
in dit geval hou ik rekening met andere scenario's waarbij de nieuwe parameter nog niet wordt doorgegeven. Begrijp dus als : om backward-compatible te
zijn. Anders zou het hier een <UNDEFINED> crash geven.

N.B. het is een public method, dus kan van eender welke plaats opgeroepen worden. Ik hou er dus rekening mee dat ik 1 of meerdere gebruikers kan gemist hebben.

[ICT-2136][rvPRA] Opkuisen logging CacheDevUT + compactDB

- method KuisOpLogsViaSelectieQueryEénRonde() : tekst voor logging aangepast

[ICT-2136][rvPRA] Opkuisen logging CacheDevUT + compactDB

- method KuisOpLogsViaSelectieQueryEénRonde() aangepast: Errors worden nu verzameld in een ExceptionList en pas na de loop gerapporteerd (Log & Mail). Na max 5 errors wordt de loop afgebroken. Dit zijn aanpassingen na review-opm van PRA, terecht.

[ICT-1339] [rvPVR] ICT: Async: Log TECH.BackgroundProcess-data, niet enkel ID
[ICT-1339] [rvPVR] ICT: Async: Log TECH.BackgroundProcess-data, niet enkel ID
[ICT-1339] [rvPVR] ICT: Async: Log TECH.BackgroundProcess-data, niet enkel ID

- Extra inhoud toevoegen bij het opstarten of bij een exceptie van een BackgroundProcess

    • -0
    • +45
    /TECH/BackgroundProcess/Helper.cls.xml
    • -1
    • +2
    /TECH/impl/BackgroundProcessStarter.cls.xml
[ICT-1339] [rvPVR] ICT: Async: Log TECH.BackgroundProcess-data, niet enkel ID

- Kleine refactor van de methode 'VoerUit'

Wim, mijn eerste indruk is dat dit gevaar loopt om miljoenen loggings te geven, als er een probleem zou zijn. Aangezien die Try .. Catch .. Log in de While-loop staat. Overweeg misschien om ook de ...

Wim, mijn eerste indruk is dat dit gevaar loopt om miljoenen loggings te geven, als er een probleem zou zijn.
Aangezien die Try .. Catch .. Log in de While-loop staat. Overweeg misschien om ook de loop af te breken zodra er één mislukt. Of om bvb. enkel de 1e en laatste en het aantal mislukte te loggen?