What are the limitations of Siebel Workflows?

This question was asked by one of readers of this blog, and it quickly got me intrigued to research for answer. While doing research I compared the capabilities of Siebel workflow vs Siebel scripting, and got amazed with results.

I started of by listing things which I thought wont be possible in workflows however I got surprised with its capabilities as I dig deeper. I am classifying results as Myths, Facts and Limitations.

Myths

Myth 1: Run time events doesn't work from workflows.

Absolutely wrong, runtime events are tagged to bus comps and work the same in workflow as they work on UI.

Myth 2: Can't update read-only fields in workflows.

One might think that as it is not possible to set admin mode to true in workflow thus it wont be possible to update read only fields. But that is simply a myth.The fact is that there is no need to set admin mode to true in workflows, read only user properties are inactivated for workflows all the time!

Myth 3: There is no way to associate and disassociate records of MVG BusComp in workflows.

If Siebel operation is used on detail bus comp, delete operation acts like dis-associate and insert like an associate.

Myth 4: Workflow can not query based on calculated fields.

Not True. Siebel Operation search spec can be created using Calculated fields, however be cautious of performance impact in case you plan to use calculated fields in search spec.

Facts

Fact 1: Cannot query on child BC directly in Siebel workflows. Workflow always queries Primary bus comp first.

True, however I don't consider it as limitation as one can create workflow based on a different BO which has child bus comp as primary buscomp, and there are many business services available which can query data from another BO without creating another sub process.

Fact 2: There is no way to change primary record in MVG in workflows.

This one I am not too sure about, would like to know from the experts, how they have overcome this problem.

Limitations

Limitation 1: It is not possible to change view mode in Workflows?
Siebel Operation step always queries database with "All View" view mode there is no way to change this pragmatically.

Limitation 2: It is not possible to pass variable by reference in to a workflow.
This seems to be the minor limitation of the workflow, however it does not limit the capability or usage in anyway.

Limitation 3: There is no native way of executing Clib functions in workflows.
There are lot of functions available for execution in workflows however Clib is not one of them. Thus if there is a need to call Clib function through workflow you will have to call a custom business service.

Limitation 4: There no native way to execute methods on application or BC level.
Agreed as limitation unless someone suggests any way out. Some BusComps exposes some methods that can be executed only with scripting. For Example: 1. RepriceAll Method on Quote Item and Order Items. 2. GetFile Methods on Attachment Buscomp etc..

 

Limitation 5: It is not possible to set sort spec on Siebel operation?
This seems to be the only glaring Limitation of workflow/Siebel Operation that Siebel operation does not contain any way to query based in a sort spec. Arguably one can say sort spec can be specified on bus comp, however it wont be wise to clone buscomp just to change the sort order. Would like to know what readers think?

I don't believe that this list is complete in anyway, hoping to get some answers from community. Please feel free to contribute your thoughts on this topic, would be more than happy to be proved incorrect on the points above.

Download Siebel Interview Questions - PDF

I have published all the Siebel Interview Questions in a easy to read PDF e-book  format, it will be available for download freely.

To get the download link, register your email and leave a comment below.

Siebel Interview Question eBook

Siebel Interview Question 2015 PDF  Contains interview questions on :

Siebel Workflow
Siebel EAI
Siebel Configuration
Siebel Scripting
Siebel Open UI

Updates to PDF will only be sent to registered readers. After registering with email do not forget to leave comment below and plus one on google to receive the link.

Get Download link:

Links Demystified

I feel no shame in admitting that it took me years to fully understand the extensibility of Siebel links. I hope after reading this post you will start appreciating the Siebel even more as I did.

Let's look at the simpler links first.

1:M links
These links creates simple parent child relationship. One parent can have many children. And children records have parent id (foreign key field).

Order Entry - Orders : Order Entry - Line Items link

Order Entry - Orders and Order Entry - Line Items is perfect example. Source Field is "Id" of "Order Entry - Orders" BC and destination field is "Order Id"  of Order Entry - Line Items. Whenever system creates a line item under an order record, Siebel populates order id on order item record with ROW_ID of Order to create relationship.



M:M links
These are also comparatively simple links. Two entities (table) are related to each other using an intersection table. Intersection table helps to associate one child to other parents as well.

Account Contact link using S_PARTY_PER

For example Account and Contact link. This link allows to associate one contact to multiple accounts. In addition to the inter table Siebel stores id of primary record ( primary id field) to improve performance.

Now let's look at the interesting bits.

M:M links with source id field specified.

In standard M:M links these fields are blank and inter table stores the ID of both parent and child records. When parent id field is also specified with inter table Siebel uses field value instead of ROW_ID of parent to create intersection record.These types of links are not very common but are possible.

For Example:

M:M link with Source Field specified

Lets consider Action/FINCORP Account link, this link has Source Field specified as Primary Contact Id which means when child records are created using this link Siebel will populate Contact Id into Inter Parent Column instead of Action Id.

M:M link with both inter table and source and destination field specified.
Things now gets more interesting when both source and destination fields are specified and inter table is also specified.This way Siebel uses fields specified on the links instead of Id to create association.

Link with both Source Field and Destination Field along with inter table.

The link shown above specifies Campain Id and Destiation Field as Contact Id, thus while creating record in inter table Siebel will use Campaign Id fields instead of Id and Same applies for destination field. Interesting isn’t it???



Finally links which are overridden by MVL's
If you are following it correctly then you might think all these complicated links should be able to satisfy all possible scenarios. Just then Siebel steps up the game with multi value links. On these MVL's definition Siebel allows to override the parent id being used on the link.

So with help of primary id field override, potentially in action to contact mvl instead listing all the contacts of selected activity, Siebel can show all the contacts of parent account selected on activity. :) This over riding is allowed both on 1:M link and M:M link.


Cheat sheet for your desk:

If you have understood all of the above then I would recommend you to explore how links are used for access control and visibility of detail bus comps.

Hope it helps.

Using MVG aggregate functions

Originally posted on blog.notesonsiebel.com on April 5th, 2007 by stuandgravy

Karan asked a question the other day: how to prevent the Status of a Service Request changing until all child Activities have been completed? This type of business rule is exactly what State Models are designed for: set up a model on Service Request Status and restrict transitions to the target status unless a condition has been satisfied. The difficulty in this example is how to write a rule based on child records?

State Model Rule Expressions use the same format as calculated field values, so the same MVG aggregate functions are available. The functions Count, Sum and EXISTS all derive a single value from a Multi Value Group and are an underused way to reduce scripting.

In the example given, Service Request has an MVG Action linked to the child Activities, so we can add a Multi Value Field to point to Action.Status.

A rule expression Not EXISTS([Action Status]<>'Done') in the State Model transition gives the desired restriction.

There’s a good example of the EXISTS function in use in the vanilla Siebel 7 repository: see BC Contact field Exists New OutBound Email Activities.

Searching Calculated Fields and performance

 Originally posted on blog.notesonsiebel.com on April 3rd, 2007

The other day I was asked whether it’s possible to search calculated fields. The simple answer is yes – as can easily be tested. The complete answer’s a little more complex: query the wrong calculated field and the application will hang, CPU resources off the scale. So how can you predict what calculations are going to cause you problems?

When you execute any query, Siebel converts the user’s logical instructions to SQL. It doesn’t always do an optimal job, but you can usually be sure that most of the effort will be pushed to the database server. The problem with calculated fields is that certain functions don’t have standard cross-platform SQL equivalents.

The IIf function, for example, will never be translated to native SQL. When your field calculation contains an IIf statement, Siebel will write SQL to return a superset of data. The Siebel object manager is then left with the job of paging through the results, evaluating the calculation for each row. Needless to say, if the incomplete SQL returns a large dataset, this ain’t going to be fast.

In any particular example it’s worth eyeballing the SQL to confirm where the calculation is happening, but you can definitely expect problems with the following functions:

IIf
IfNull
ToChar
Right

Unfortunately, there’s no configuration way to prevent searching on an unpleasant field. If you’re running into problems then you’ll have to hit the PreQuery event with some scripting…

Changing the Local Database Password

 Orignally posteed on blog.notesonsiebel.com on March 29th, 2007 by stuandgravy

Users forget their passwords – that’s just the way it is. Without picking on anybody, certain users (cough sales guys cough) are particularly prone to this. And more often than not, they’re remote users who’ve not synchronised their local database for a week and desperately need their updates.
As with the server database, there’s no way to retrieve the current local database password. Password hashing algorithms are repeatable, but not reversible – sensibly enough. It is possible to change the password to something new though.

Connect to the local database, then run these SQL commands:

grant connect to USERNAME identified by PASSWORD
grant connect to SIEBEL identified by PASSWORD

Where USERNAME is the login for this database and PASSWORD is the new password (both in upper case). If for some reason you don’t know who the local database belongs to, the login can be retrieved with this command:

select name from SYSUSERAUTH
where name not in ('SYS','DBA','PUBLIC','SIEBEL','DBO','dbo','SSE_ROLE')

More often than not, you’ll also want to reset the server database password to match, so that you can sync up those outstanding changes. On Oracle, this is your usual:

alter user USERNAME identified by PASSWORD

There’s more info in SupportWeb TechNote 25, including scripts for different versions of SQL Anywhere to automate the process.

How to interview a Siebel Resource?

Originally posted on blog.notesonsiebel.com on March 26th, 2007 by stuandgravy

I’ve interviewed a bunch of Siebel techies and have evolved a few favourite questions, all based around the same theme: attempting to uncover technical breadth while avoiding obscure ‘gotcha’ questions. Things like this:

Q: How would you update a second field every time a first field is changed?

This is a great question: simple enough that a junior dev straight out of a tools course should come up with a few options and have some idea how they weigh up, but broad enough that a senior techie can lead you into detailed discussions about performance vs maintainability, good practices, upgrade issues, etc etc.
If the candidate’s running out of steam, leading questions can coax them toward more inventive answers.

For instance:

• What if the second field is in a different business component?
• What if there are multiple fields to be updated?
• What if the second update needs confirmation?
• What if the update still has to happen for batch (EAI/EIM) updates?

To the answer: I reckon the following is not a bad list to cover-off, but there’s still a few missing…
User Properties
+ minimal config
+ real time
+ robust (mostly!)
- limited
- require srf update

Runtime Events to Workflow Process
+ most things possible with native, compiled Siebel Operations
+ declarative, flexible, upgradable without srf update
+ long-running workflows for multiple consecutive events
+ real-time, optional asynchronous
- no loops (almost) without custom business services
- overhead of instantiating the workflow first time (then cached), which can have a big impact on mobile users

Server scripts
+ simple to write
+ low overhead
- not declarative, requires srf release
- higher level than vanilla C++ services (so slower, in theory)
- limited possibility to interact with the user


Browser scripts
+ opportunity for full manipulation of DOM, real-time interactivity
- maintenance headache (generating script, keeping versions current)
- interpreted at run-time (so slower, in theory)
- limited speed, memory space etc

Workflow Policy to Workflow Process
+ fully robust database-level trigger
+ fully asynchronous
- not real time, interactive
- not declarative, requires DBA maintenance

Locally unlocking a locked Project

Originally posted blog.notesonsiebel.com on March 22nd, 2007 by stuandgravy

With multiple developers building one application it’s inevitable that multiple developers will need to change the same project at the same time. There’s pros and cons and object-locking and change-control and build-control etc etc, but sometimes deadlines are too tight and you just have to fork.

In Siebel Tools, once one developer’s got a project locked the UI won’t let a second developer anywhere near it. To get around this you need to get into SQL Anywhere. Login to the second developer’s local database, then the following script will unlock the project locally:

UPDATE s_project
SET locked_flg = ‘N’
WHERE name = <Project Name>

The second developer can now log into Siebel Tools, manually lock the project as normal and do what she has to do. Of course, once build is done the two developers will need to go through a merge exercise to get their changes into the one repository, but that effort can be preferable to losing days of development time.

Siebel PropertySet Demistyfied [Infogrpahic]

This is my first post in response to analysis of Google Analytics search reports. In this series I will look at search terms searched by Siebel developers on Google and try to answer them with infographics.

Recently someone landed on How to Siebel? by searching keywords on Google: "Difference between GetValue() and GetProperty()"

There is ample information available on property set methods in bookshelf. Here is my answer using infograph.

Siebel Property Set Methods

GetValue() method returns the value of the property set, in example above  output will be : "My Value"

GetProperty() method returns the value of the specific property, in above example GetProperty("Weight") will return "1500"

If you looking for advanced property set concepts and traversing methods, then I will recommend going through How to traverse property set @ SiebelUnleashed

To receive more articles like this please subscribe via email by submitting form below.

Remove tiny X icon from MVG and Picklist fields in Internet Explorer

MVG and Picklist fields of Siebel IP2013 shows a tiny X icon on right end, on clicking this icon data in the field is cleared. Due to awkward positioning user end up clicking it unintentionally. This behaviour is only available for IE browser.

X in Account Field

X in Currency Field

This was added by oracle in hope to improve usability, but it has received lot angst from end users. Instead of improving user experience it risks of losing data in case of miss click.

Luckily there is simple css solution to remove this icon. Following line in your custom css can remove this unnecessary usability trick from entire application.

input:focus[type="text"]::-ms-clear{display:none;}

Input text fields with this css looks amazing just as in chrome and firefox.

CSS fix for Pick list fields

Currency Field in Siebel Open UI

Hope it helps.