Siebel Code Challenge – #9

April 12, 2012 By 6 Comments

UPDATED: Thanks to Rick for spotting this one! The Today() function returns today’s date without a time component. As there is specialised class validation functionality all over the Action BC, the Workflow will fail if the planned start date is any time today – regardless if it’s before the current time or not. Using the Timestamp() function, within the operation step, will achieve the result expected by the developer.

By special request from Rahul, I give you Siebel Code Challenge #9 – Return of the Code Challenge!

This is something I came across recently – you need to think about the context of vanilla validation in the Action BC to realise why this Workflow isn’t quite right.

This is such a simple mistake but one that can really affect the logic that the developer has in mind. Comments and answers below, please!

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)
Filed Under: Code Challenge, Configuration, Siebel, Workflow Tagged With: , , ,

Siebel Code Challenge – #8

April 1, 2012 By 5 Comments

UPDATED: Once again, Rahul has spotted the issue. In this case, the developer has used an exception connector to connect the exception handling Business Service to the End step. This should be a default (black) connector, not the exception (red) connector.

Interestingly, the workflow will still run through but the exception handling step itself will raise an exception that will be thrown out of the workflow!

A REALLY easy one today! When maintaining or reviewing code and configuration, do not underestimate the stressed and hurried developer. This is something I came across a lot in a previous engagement and it’s something that one developer had got wrong in their head and propagated around the system. A real pain to tidy up!

Answers in the comments box below please!

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)
Filed Under: Code Challenge, Configuration, Siebel, Workflow Tagged With: , , ,

How old are you really?

March 28, 2012 By 4 Comments

Sometimes I come across something in Siebel that just blows my mind: often it’s some awesome, supercool functionality. But sometimes, just sometimes, it’s something so mind bogglingly stupid that I have to look again, just to make sure I read it right!

Today, I found out that the vanilla ‘Age’ field, on the Contact BC, uses the following calculated expression:

Now, this isn’t even worthy of my Code Challenge! Since when was there ever exactly 365 days in a year? How could one of the worlds largest technology organisations consider this to be a good solution to a simple requirement? What’s best is the response to the bug report that this calculation doesn’t consider leap years and so would actually return the wrong result:

The Age Calculated Field is Not Working with Standard (or Vanilla) Configuration. [ID 1385094.1]

The scenario mentioned here is expected (as per the vanilla logic used)… This formula does not take into account “Leap Year” in the calculation..  As a workaround, create a custom calculated field with custom logic (examples are available with google searches) that will calculate the age of the person considering the leap year…

I’ve highlighted my favourite words: as one of my colleagues so eloquently put it: “WTF?”

We especially liked how “Leap Year” was in quotes as if to say it’s kind of a mythical thing that you can choose to believe in – or not. If nothing else, this did make us chuckle!

A kindly Siebelite, named JDijkhuis, has done the honors of posting a solution on the IT Toolbox site, that we have tested successfully. Beware, though, as I’m not sure about the performance impact if this were exposed through a list applet. I’ll let you follow the link to the kindly gent’s web site so as to give full credit for the solution.

The mind truly boggles! :)

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)
Filed Under: Configuration, News, Siebel Tagged With: , , ,

Siebel Code Challenge – #7

March 26, 2012 By 5 Comments

UPDATED: Thanks to Maurice for posting the correct answer, in addition to spotting my ‘deliberate’ mistake of failing to add a ‘default’ branch to the ‘Records?’ decision step!

The issue is that the process property ‘Valid’ is updated each time a record is assessed – the net result is that the Workflow property will only ever contain the result of the last record processed. It is highly likely that this behaviour is undesirable. A working solution would be to default the property to ‘Y’ then drop out of the loop the moment a record returns ‘Invalid’, setting the process property to ‘N’. This would also prevent processing of any additional records should an invalid one be found.

Another workflow for you today. This is a logic error that I came across recently – it looks innocuous but the impact could be quite significant:

The Workflow outputs the ‘Valid’ property, for use by the calling process to determine whether all contacts queried were valid or not. If you spot the issue with this workflow, post below!

VN:F [1.9.17_1161]
Rating: 8.0/10 (1 vote cast)
Filed Under: Code Challenge, Configuration, Siebel Tagged With: , ,

Error Logging, Object Properties and ‘arguments’

March 20, 2012 By 6 Comments

I’ve been working on enhancing and fixing a customer’s error handling routines. We have a pretty good system in place, providing a single Business Service with methods to log script and Workflow errors. We capture as much information as we can about an error and the object that was being processed, and we stick in all into a custom table. All very good!

I wanted to see how we could extract more consistent and reliable information out of Siebel while creating error messages in the log. For example, I want to programatically derive:

  1. The object type (e.g. BC, BS, Application, Applet, Workflow)
  2. The object name (e.g. HLS Case, Case List Form Applet)
  3. The Workflow Process name and version number
  4. The method / function name or Workflow step (e.g. BusComp_PreSetFieldValue)

I want a way to derive this information automatically, so that there is no manual coding of any of the information in the error handler script or workflow step. This means I can standardise the handler across all objects without the worry of entering incorrect information or having to manually derive the information myself.

I came across some useful information on MOS and in Bookshelf:

  • Use the this.Name() method to derive the name of the Applet, Business Component, Business Service or Application in which eScript is being invoked
  • Use the arguments.callee object and property to derive the name of the method or function being invoked

Now, I’ve never come across the ‘arguments’ object before. Looking at the specification for EMCA 262, I find reference to this as a standard JavaScript object – and it seems to have made it into eScript. However, on retrieving the ‘callee’ property, I get back the rather useful string “Compiled Function”. So I can’t seem to use this to determine the function or method name.

Calling out to the Siebel community at large!

  1. Has anyone successfully used the ‘arguments’ object to do anything useful in eScript?
  2. Does anyone know of a way to programmatically determine the name of the method within which the error occurred?
  3. Can the object type be derived programmatically?
  4. Is there a way to derive a Workflow’s name and version within the Workflow itself?

Please let us all know if you have any thoughts in the comments box below!

VN:F [1.9.17_1161]
Rating: 9.0/10 (1 vote cast)
Filed Under: Configuration, eScript, Siebel Tagged With: , ,
« Previous Page
Next Page »