UPDATED: My old friend Terrence was the first to spot the ‘deliberate’ mistake. Property sets can be your friend – they offer a persistent and flexible mechanism to move pairs of name, value strings across entities. However, the Siebel compiler is unable to spot situations where not all control paths set an expected value on the output property set. In this case, we were seeing occasional errors in our logs with the text “Argument ‘x’ in step ‘y’ is not correctly initialized or does not return valid data”. This is because the code was failing to set an expected output value which caused the Workflow to throw an exception and prevent a critical business process from executing correctly.
Another anomaly for you to decipher – an easy one again today! Once more, I must emphasise that these are examples of code and configuration that I’ve found in live, Production Siebel environments. I’m not posting these to shame anybody (well, maybe a little) but to show how the simplest mistake or ommission can comprimise the functionality and data quality within Siebel.
Virtual prize for the first to point out the obvious mistake!
Note that this function forms part of a Business Service that is invoked from a Workflow Process Step. The Process uses the output to determine what to do next.
function CodeChallenge3(Inputs, Outputs)
{
// Declare variables
var boContact, bcContact;
try
{
// Instantiate new BC instance
boContact = TheApplication().GetBusObject("Contact");
bcContact = boContact.GetBusComp("Contact");
with (bcContact)
{
// Create query context
ClearToQuery();
SetViewMode(AllView);
SetSearchSpec("Id", Inputs.GetProperty("ContactId"));
ExecuteQuery(ForwardOnly);
// Record is found
if (FirstRecord())
{
Outputs.SetProperty("Found", "true");
}
}
}
catch(e)
{
// Call the custom LogError function to write error to error log
LogError("Woops, an error has occurred!");
}
finally
{
// Destroy objects
bcContact = null;
boContact = null;
}
}
Answers on a postcard or post in the comments block below!



