Making dynamically Field Read only at UI or Applet level

Making dynamically Field Read only at UI.

There are several areas we may get requirements to have field read-only dynamically at UI/Applet level. So, generally most of us uses Field Read-Only Field BC user property by using some calculated fields or flags to implement this But  field will not be editable for updating from Script/WF or any other interfaces. 

We can achieve this by using Applet Level user property "Read Only Field N". This user property allows you to make field read only on UI, by allowing field updates from workflow or scripting. 


The syntax goes like:

Name: Read Only Field 1
Value: 'FieldName', 'ConditionFieldName'

FieldName = Name of the field which we want to be read-only
ConditionFieldName = Name of the field which specifies condition to be read only

@Prakash

Overview of Siebel Task Based UI

Basic Overview:

Siebel Task Based UI is a new framework that allows automation at each tier in a N-Tiered architecture, mainly having 3 layers User interface layer, Business Logic Layer, Data access layer.

User Interface layer is a Wizard like UI to automate the user interaction with Forward/Backward navigation and having Pause/resume capabilities with the help of universal Inbox integration.

Task writes all the transactions into a temporary shadow storage table called S_TU_LOG which is managed by Siebel Object Mgr. 

 Within Task we can include Siebel Operation steps, Business Service, Task Views, Decision Step and error message steps to perform the operations.


Tasks can access the data from both transaction tables as well as shadow tables.


Data can be stored temporarily with the help of transient BCs which are uses shadow tables and these BCs can be used in the Task's Operations.


All Task views can consist of all types of Applets like list applet, form applet, chart and tree applets. Task view must includes a 'Playbar' applet which is used to control the navigation.


By using the playbar applet we can control below navigations - 


Pause - it save the Task instance in the user's My Inbox view and user can resume/Transfer/Delete the Task later. Paused task data will not be committed to the transaction database tables.


Previous - user can navigate to the previous task view.


Next - user can navigate to the Next task view.


Cancel - task will be canceled and the data stored in the shadow table will be cleared.


Submit - this will be the last step of the task flow which commits the data.


Once the task is completed or reaches the End step in the Task flow then Commit transaction will performed to merge/store the data with the transaction tables and after the shadow tables data will be cleared.


User will be navigated back to the original adhoc view where he started the task.


We will know how to develop a task and invocation in next Post.


happy reading.
@Prakash