Comparing properties in Siebel Workflow

I came across this in a live Workflow the other day:

What’s happening here is that the comparison of two Workflow Process properties is being done in a custom, eScript Business Service. Further digging revealed that the ‘Is Num >= Max?’ step invoked the following eScript:

function GreaterThanOrEqual(Inputs, Outputs)
{
  var res = "Y";
  var val1 = new Number(Inputs.GetProperty("Value1"));
  var val2 = new Number(Inputs.GetProperty("Value2"));

  if (val1 >= val2)
  {
    res = "Y";
  }
  else
  {
    res = "N";
  }

  Outputs = res;
  return (Outputs);
}

Apart from the obvious problems with this code, it struck me as a very round about way to compare two properties within a Workflow.

So I replaced it all with a single, expression based decision step:

Does anyone have any examples of their own of ‘over engineered’ solutions to simple problems?

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

Siebel Code Challenge – #9

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)

Siebel Code Challenge – #8

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)

How old are you really?

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)

Siebel Code Challenge – #7

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)