Programmeren is leuk. Vind ik. Een Siebelconfigurator wordt echter geleerd dat eScript alleen ingezet mag worden als er geen andere manier voor handen is. Onder de zogenaamde User Properties is een hele reeks voorgeprogrammeerde functies beschikbaar. User Properties in plaats van eScript is goed voor het beheer van de applicatie en migratie naar een volgende Siebelrelease wordt er eenvoudiger door. Oracle hangt deze werkwijze ook aan, zoals we tijdens de cursus ook ondervonden hebben. eScript komt niet of nauwelijks aan de orde.

Je zou verwachten dat de mogelijkheden binnen Tools dit ondersteunen. In plaats daarvan wordt eScript via de debugfunctionaliteit veel beter ondersteund dan de User Properties. Op het project waar ik nu zit, wordt gewerkt met Siebel 7.8. De keren dat ik trachtte een User Property aan de praat te krijgen, begon ik met niets, waren de tussenresultaten niets en eindigde ik met niets. Dit wordt zonder meer veroorzaakt door mijn geringe ervaring met de user properties. Maar tekenend vond ik wel dat ik met eScript het wel voor elkaar kreeg. Helaas was dat niet de bedoeling. Met de break points in het script en de watch window waarin de tussenresultaten zichtbaar zijn, kun je werkelijk debuggen. Je kunt er mee opsporen waar het programma er uit vliegt of waar verkeerde waarden worden toegekend. Helemaal wat je van een debugfunctie verwacht. Met deze manier van werken heb ik kunnen aanschouwen wat de verschillen zijn in PreSetFieldValue en SetFieldValue. Reuze inzichtelijk. Er bestaat een knop om de syntax te controleren. Helemaal geweldig.

Maar dan de User Properties. Je kunt het valideren, maar geen fouten in de validatie garandeert niet dat er iets gebeurt met het onderwerp van de property. Dat de validatie succesvol verloopt, zegt hoegenaamd niets over de juistheid van de syntax. Het is gevoelig voor spaties en enkele of dubbele aanhalingstekens, maar daar zegt de validatie niets over. Dat lijkt me toch iets waar Tools op zou moeten kunnen controleren. Ter illustratie staan hieronder twee regels voor de value van een On Field Update Set. De eerste was één van de minstens 30 varianten die ik probeerde en die niet werkte. De tweede werkt wel en is gemaakt door mijn collega Noredine die minder snel gefrustreerd raakt en die handiger is in het zoeken in bestaande User Properties. Want dat is het recept, zoek in materiaal dat wel werkt en wat lijkt op wat jij wilt maken.

Goed:  "Diplomacode", "Diplomadatum", "IIF([Diplomacode] = LookupValue(""DIPLOMA"", ""1""),[Diplomadatum],"""")"
Fout: "Diplomacode", "Diplomadatum", "IIF([Diplomacode] = LookupValue(""DIPLOMA"", ""1""),[Diplomadatum],"" "")"

Zoek het ene verschilletje.

Zoals gezegd, ons project werkt met 7.8. Laatst kreeg ik op een kwade dag met mijn dedicated client geen toegang tot de server zodat ik niet kon uittesten of mijn User Property met een Julian-functie het gewenste effect had. Het was buiten kantooruren. Hierdoor zag ik geen mogelijkheid om de toegang te herstellen. Omdat ik erg graag wilde weten of Julian deed wat ik wilde, week ik uit naar een VM-ware-image die op mijn laptop staat. De Siebel daarin is 8.0 en heeft een editor functie voor de value property van de User Property. Prachtig. In de Calculated Value property van Fields zit hij trouwens ook. Ik werd er helemaal enthousiast van. Het is geen debugger, maar als je bij niets vandaan komt is dit heel mooi. Hieronder een plaatje ervan. Let niet te veel op de Expression, die slaat eigenlijk nergens op, weet ik inmiddels.

Als je een haakje toevoegt aan de Expression, wordt het haakje dat volgens Tools er bij hoort geel gekleurd. Net als in Excel, maar alleen als je het net ingetypt heb, daarna verdwijnt de kleur weer. Dus als je een haakje sluiten typt en er wordt niets geel, dan mist er iets. Je kunt beschikbare Fields selecteren en dan zet de editor er ook meteen vierkante haken omheen. Very convenient, en ook tegen hinderlijke typefouten.

De opdracht die ik had gekregen was de volgende. Zorg er voor dat een bepaald datumveld op drie weken later wordt gezet dan een ander datumveld en doe dit met een Julian-functie. En die heb je nodig omdat de ‘drie weken later’ afgerond moet worden naar boven, naar bijvoorbeeld de eerstvolgende maandag. Althans, dat begreep ik uit het verhaal. Nu ik een paar uur met Julian gevochten heb, denk ik dat ik nog maar eens navraag moet gaan doen naar de precieze strekking. Wat een rare functie, die Julian. In de Tools-helpfunctie vond ik het volgende.

JulianYear (): Equal to the current year + 4713.
JulianWeek (): JulianDay() / 7, rounded down to the next integer.
The Julian functions must include Today() or a field name as a parameter.
For example, you need to use either JulianMonth([Created]) (of a field) or JulianMonth(Today()) (of the current date).

Hier maken we uit op dat Julian ergens in de oudheid begonnen is met de dagen te tellen en wel 4713 jaar voor Christus. JulianDay([Datum]) is het aantal dagen vanaf de grijze oudheid tot en met [Datum].

Als je in een User Property 21 optelt bij een datum, dan telt Siebel er 21 dagen bij op. En blijft het type Datum. Dat is prettig rekenen. Nu moeten er voor de eerstvolgende maandag nog een paar dagen extra bij op, indien de datum geen maandag is. Maar hoe in den vrede gebruik ik JulianWeek of –Day daarvoor.

In de Bookshelf stond precies dezelfde tekst als in de online-help, dus dat voegde niets toe. Op metalink3 vond ik geen voorbeelden van hoe je een Julianwaarde weer terug zet in een datum. Nou, toen ben ik zelf wat gaan vogelen. Zonder succes overigens. Ik dacht, JulianWeek is gelijk aan JulianDay/7 en dan afgerond naar beneden naar de eerstvolgende integer. JulianWeek is het aantal hele weken sinds de vroege oudheid en het deel van de huidige week telt niet mee. Dus JulianDay/7 minus JulianWeek is een breuk van een aantal zevenden. Leek me logisch. Die breuk vermenigvuldigd met 7 is het aantal dagen van de week dat al voorbij is. En die moet ik kunnen gebruiken om te bepalen hoeveel dagen er nodig zijn om op de eerstvolgende maandag te komen. Nog een voorwaardelijke Calculated Value er tegenaan zetten voor het geval dat we al op maandag zitten en dan heb ik m’n eerstvolgende maandag na de drie weken na de oorspronkelijke datum. Dat was het plan.

De Value property van de On Field Update werd een beetje gecompliceerd door de Julians en de optellingen, delingen enzo. Het werkte niet in de zin van dat het geen effect had op de datumvelden. Er gebeurde gewoon niets, geen foutmelding, niets. Omdat de Julians van een ander type zijn dan de data, had ik behoefte aan een watch window om te zien wat die Julians voor waarde hadden als ik er mee ging rekenen.

De Business Component ‘PUB HLS Incident’ had ik uitgezocht om in de image de Julian-functies uit te proberen vanwege de datumvelden die hierin voorkomen. De applet met details over de Incident heeft een veld Description en deze leek me geschikt om als watch window te dienen. En zo kwam ik er achter dat Siebel niet van breuken houdt. JulianDay/7 wordt net zo afgerond als JulianWeek. JulianDay/7 minus JulianWeek is identiek gelijk aan 0. Jammer.

Klik op afbeelding om te vergroten

Julian helpt me nog niet aan de eerstvolgende maandag, maar ik heb nu wel m’n eigen watch window voor User properties die ik miste bij het debuggen.

Victoria Hoogenveen