22
Jul
2009
Siebel – Fetch Active view properties
by Nitin JainHi,
Working on a typical requirement recently, I came across a need to fetch the properties from the user’s active view. This was an attempt to recognize the user, and the details about the Siebel view/screen he was in.
On research we can see that there are a number of Application level methods which we have at our disposal.
We see that we can get the active Business Object name using the format:
TheApplication().ActiveBusObject();
Also, the active view name may be fetched using:
TheApplication().ActiveViewName();
The Login Id of the user logged in may be fetched using:
TheApplication().LoginId();
The Name of Logged in user (the one that is typed into the Login box) may be fetched using:
TheApplication().LoginName();
The Position ID may be fetched using:
TheApplication().PositionId();
The position name of the user logged in may be fetched using:
TheApplication().PositionName();
.. and maybe some more, in case I missed out on any.
However, this is very limited information (though may be sufficient for some requirements). More so, if we notice, the information is mostly User oriented rather than being Siebel session oriented.
We will explore further if there is a way to get more detailed information of the current view. Even simple topics turn into series of posts. There is so much to explore and share in Siebel..!! 
Related posts:
- Siebel – Fetch Active view properties – II We discussed about fetching the values from the active view...
- Siebel – Fetch Active view properties – III I will discuss a practical example, and the corresponding Inputs...
- Siebel Assets List view – Performance issue / Cannot display records Assets Screen Load is a major problem in Siebel, and...
- Siebel – Admin Mode Flag In my last project,we had a requirement of Admin Views,...
- Siebel – Popup Update Only Hi all, I was working with Siebel Multi Valued Links...
- Siebel Admin Mode Flag – II – Issue Log In the last post I described about Admin Mode Flag....
- Siebel – ActivateField() split wide open In Siebel, we generally tend to use the fields on...
One thing I’d like to add here is a note about Integration.
We had a requirement to refresh (ExecuteQuery()) a bc after a record was written. Lets call this BC-A. Initially we simply had some code in the WriteRecord() event using ActiveBusObject().
We also had an integration piece that was accessing BC-A using workflow. As we all know, when defining a workflow we define a Business Object.
What happened is that when the workflow ran, the business object defined did not include all of the bcs that were defined on BC-A’s script. So what we had to do is first determine if we were on the correct view. For this we used ActiveViewName(). But then what we used to determine the correct BO was to use this.BusObject() which will determine the bc’s BO.
This approach made sure we were accessing the BC’s business object and not the Workflow’s business object.
Hope I was clear and not too confusing. The gist is that you may need to use this.BusObject() in some cases as I did.
I understand. Nice tip, Denis!
This problem would come up when you are trying to access a BO different from the one defined on Workflow Definition. I generally used a different kind of solution in this case. Let’s sum it all up:
1) Use this.BusObject() in script in this case, as suggested by Denis.
2) Use a sub-process within the workflow if you want to work on a different BO. You can avoid scripting this way.
3) Don’t use a BO on the Workflow Definition at all, unless absolutely necessary. This works just as well.
Thanks for sharing, Denis. Cheers!