CacheAdminACommon_trunk2010/vhLib/WebServiceLogger

LogService.cls.xml

Checkout Tools

Line History

Line Count Graph
Line Count Graph

Stats

Commits this week: 0
Total Committers: 5
Last Commit: 24 Aug 20
Commits this week: 0
Total Lines of Code (LoC): 94
Net change in LoC this week: 0

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Tuesday 02 Feb 2021
10:39 am

Wim Vermeulen

Monday 01 Feb 2021
4:56 pm

Jelle Baele

Ok top, bedankt!!

Ok top, bedankt!!

4:06 pm

Wim Vermeulen

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

3:45 pm

Wim Vermeulen

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.

Friday 29 Jan 2021
12:37 pm

Jelle Baele

12:37 pm

Jelle Baele

Volgens mij is hier alles juist voor zover ik mee ben. Ik snap wel het principe van het afzonderen naar de WebServiceHelper door het object via $this mee te geven zodat er minder grote compileerti...

Volgens mij is hier alles juist voor zover ik mee ben.

Ik snap wel het principe van het afzonderen naar de WebServiceHelper door het object via $this mee te geven zodat er minder grote compileertijden zullen zijn bij het aanpassen van iets in te toekomst. Over de algemene werking zelf snap ik wel niet perfect wat er juist allemaal gebeurt (bv. waar de 'MsgClass' van de webservice zelf voor staat (Die wordt opgeroepen in 'vhLib.WebServiceLogger.Logger^GeefWebMethodFromService'))

12:22 pm

Jelle Baele

Hier hetzelfde, $G -> $Get?

Hier hetzelfde, $G -> $Get?

12:21 pm

Jelle Baele

Moet volgens de coding conventions hier niet '$Get' geschreven worden in plaat van $G? Snap ook niet zo goed waarom hier een $Get gebruikt wordt?

Moet volgens de coding conventions hier niet '$Get' geschreven worden in plaat van $G?

Snap ook niet zo goed waarom hier een $Get gebruikt wordt?

Thursday 28 Jan 2021
11:58 am

Wim Vermeulen

[ICT-1756] WebServiceLogger geeft "Unknown webmethod"
[ICT-1756] WebServiceLogger geeft "Unknown webmethod"