1 / 51

TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES

TOPICS. TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES. TRANSACTIONAL TBUI. BRIEF DESCRIPTION Allows data to live for a short period of time. Data is last as long as the task instance is set in PAUSED state. An inbox item holds the task instance to keep its data alive.

bryga
Download Presentation

TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TOPICS TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES

  2. TRANSACTIONAL TBUI BRIEF DESCRIPTION Allows data to live for a short period of time. Data is last as long as the task instance is set in PAUSED state. An inbox item holds the task instance to keep its data alive. Commits data to the database when a commit step is issued within the TBUI. Becomes transactional when the Transactional property of Task flow is set to TRUE. By default, a TBUI is set to execute in a transactional mode.

  3. TRANSACTIONAL TBUI • ADVANTAGES • Data can be held in memory for any amount of time. • Data can be rolled back at ease, if need be. • DISADVANTAGES • First commit in task flow takes enormous amount of time. At times, unknown and strange errors appear on click of Next button. • One such error is - the user keys at the table level fail to get satisfied. For an effective performance, multiple commit steps need to be used.

  4. LOOK N FEEL OF A TYPICAL TRANSACTION TBUI

  5. NON TRANSACTIONAL TBUI • BRIEF DESCRIPTION • Allows data to get stored into the database instantly. • No need to use a Commit step in the task flow. • Two ways to make a TBUI non transactional. • Set Transactional property of the task flow to FALSE. • Set ‘Immediate Commit in Task’ user property to TRUE for every BC used in TBUI. • Important Note: Oracle – Siebel suggests a transactional task flow. Nevertheless, • It’s practically proven that non-transactional TBUI performs better.

  6. NON TRANSACTIONAL TBUI ADVANTAGES Performance of TBUI is phenomenal due to instant commits. TBUI looks tiny, compact and tidy due to elimination of multiple commit steps. No strange errors occur during the navigation with in task views. Queries to fetch entered data between task views become easier. DISADVANTAGES Data cannot be stored into the database at will. Data entered cannot be rolled back. Designing a roll back process is a painstaking process.

  7. LOOK N FEEL OF A TYPICAL NON TRANSACTION TBUI

  8. MAINTAINING THE CONTEXT OF THE TASK VIEW ONE WAY Query on the business component using Siebel Operation step. This maintains the context of the queried record through out the TBUI. Make sure the ‘Retain Task Search Spec’ of Siebel Operation step is set to TRUE. Refer to the diagram in impending slides. ANOTHER WAY In addition to the above steps, the following has to be done. Make sure to have a Task Step Context consistently across all Task Views. Refer to the diagram in impending slides.

  9. MAINTAINING THE CONTEXT OF THE TASK VIEW The Siebel Operation step (grey in color) makes sure that the queried record would Appear across all the task views within the task flow (with some exceptions).

  10. MAINTAINING THE CONTEXT OF THE TASK VIEW Notice the Task Step Context configured for the task view.

  11. MAINTAINING THE CONTEXT OF THE TASK VIEW An applet should hold an active record for a successful launch of a TBUI. An active Record is mandatory for the TBUI to maintain the context across the task views. SIMPLEST CASE Is to operate TBUI on the currently selected record in the applet. No query or insert Siebel operation step is required to maintain the context. COMPLEX CASE Is to operate TBUI on a record that is not currently selected in the applet. An insert or a query Siebel Operation step is required, and it is preferable To maintain the task step context across the task views within the task flow.

  12. PASSING TASK PROPERTIES TO A TASK FLOW By default, the following task properties are passed to the task flow. Object Id Context BC Id Context BC Name No custom task properties could be passed to a task flow. Note: Oracle – Siebel to implement this feature in the future releases.

  13. LAUNCHING THE TASK FLOW Launching a task flow through script bsTask = TheApplication().GetService(“Task UI Service (SWE)”); psIn = TheApplication().NewPropertySet(); psOut = TheApplication().NewPropertySet(); psIn.SetProperty(“TaskName”, “Task Name”); bsTask.InvokeMethod(“LaunchTask”, psIn, psOut); LaunchTask and LaunchTaskFromScript are two methods that can be used. Till date, launching a task is successful through script. Note: Not sure how it works through the configuration of Method Invoked and The control user properties of the control. MethodInvoked = LaunchTask Control User Prop: Task Name = <Task Name>

  14. RESUMING THE TASK FLOW PROGRAMMATICALLY Resuming a task flow through script bsTask = TheApplication().GetService(“Task UI Service (SWE)”); psIn = TheApplication().NewPropertySet(); psOut = TheApplication().NewPropertySet(); psIn.SetProperty(“TaskName”, “Task Name”); psIn.SetProperty(“Object Id”, “Instance Id of the Task”); bsTask.InvokeMethod(“ResumeTask”, psIn, psOut); Not documented, ResumeTask can still be used to resume a task. VANILLA FEATURE Drilling down on the inbox item of type task resumes a task flow.

  15. GETTING OUT OF THE TASK FLOW PROGRAMMATICALLY Like ResumeTask , the other hidden methods can also be used. For instance, NavigateNext can be used to go out of the task flow as below. On a button click, the below code will be executed. The below codes automates the process of clicking Next button on task view. The task flow then contains a decision point to check if the condition is met. If the condition is met, the task flow gets ended. bsTask = TheApplication().GetService(“Task UI Service (SWE)”); psIn = TheApplication().NewPropertySet(); psOut = TheApplication().NewPropertySet(); bsTask.InvokeMethod(“NavigateNext”, psIn, psOut); Note: Practically, the methods of Task UI Service (SWE) are working only at Applet level. They do not behave in the same way when executed from a business service. One part of the previous task flow diagram has a similar kind of implementation in it.

  16. CREATING ANOTHER TASK WHILE A TASK IS RUNNING Creation of a task is allowed through a Task workflow step. The new task gets created and parks it in the inbox. The task workflow step takes care of assigning an owner to the task as well.

  17. RELATIONSHIP AMONGST RECORD, TASK AND INBOX On an incident record, launch a task. Task instance gets created. Pause the task. An inbox item of type Task gets created. The inbox item holds the task instance. So, the relationship, in reverse, is something like this. Inbox Item ------ holds the task instance. The task instance -------- holds the record on which the task is initially launched.

  18. HOW TO GET TASK INSTANCE THAT IS RUNNING ON A RECORD • The following script helps you know the task instance that’s paused on a record. • boTask = TheApplication().GetBusObject(“Task”); • bcTask = boTask.GetBusComp(“Task Instance”); • bcTask.ClearToQuery(); • bcTask.ActivateField(“Instance Id”); • bcTask.SetViewMode(AllView); • bcTask.SetSearchSpec(“Workitem Id”, <Record Id>); • bcTask.ExecuteQuery(ForwardOnly); • If (bcTask.FirstRecord()) • strInstanceId = GetFieldValue(“Instance Id”); • strInstanceId is the task instance, which is running on <Record Id> • <Record Id> is the ROW_ID of an incident or an action or any other entity.

  19. HOW TO GET INBOX ITEM THAT’S HOLDING TASK INSTANCE • The following script helps you know the Inbox item associated to Task Instance. • boInbox = TheApplication().GetBusObject(“Uinbox Item Task”); • bcInbox = boInbox.GetBusComp(“Uinbox Item Task”); • bcInbox.ClearToQuery(); • bcInbox.SetViewMode(AllView); • bcInbox.SetSearchSpec(“Item Object Id”, <Task Instance Id>); • bcInbox.ExecuteQuery(ForwardOnly); • If (bcInbox.FirstRecord()) • strInboxId = bcInbox.GetFieldValue(“Id”); • strInboxId is the inbox item ID, which is holding Task Instance. • <Task Instance Id> is the instance ID of the task that’s running on a record.

  20. TRANSFERRING A TASK • Two methods that are helpful in transferring a task. • ‘UpdateInboxItemInfo’ method of Universal Inbox Business Service • ‘Transfer’ method of Task Administration Business Service • Transferring a TBUI is mainly based on two fields of the Inbox Item • Requestor ID field • Approver ID field • The login ID of the one who is transferring should be the value of Request ID field. • Without this, the transfer would never happen to another person.

  21. TRANSFERRING A TASK The following script makes sure that the Requestor ID is properly updated. bsInbox = TheApplication().GetService(“Universal Inbox”); psIn = TheApplication().NewPropertySet(); psOut = TheApplication().NewPropertySet(); psIn.SetProperty(“InboxTypeName”, “Task”); psIn.SetProperty(“ObjectId”, strInstanceId); psIn.SetProperty(“InboxPartyId”, TheApplication().LoginId()); bsInbox.InvokeMethod(“UpdateInboxItemInfo”, psIn, psOut); strInstanceId is the task instance, which is being held by Inbox. The red-marked line makes sure that the user A who is transferring the TBUI is the actual requestor of the transfer. And the Transfer method of Task Administration makes sure that the Approver ID (Task Owner Id) is updated to the user B’s login ID. Thus, completing the transfer from user A to user B.

  22. TASK ADMINISTRATION METHODS • Task Administration business service has some useful methods. • Transfer – transfers the task from Owner Party Id to another Owner Party Id. • CreateTask – Creates a task instance and assigns it to a given owner ID. • DeleteTask – Deletes a task instance, provided the instance ID. • Associate – Helpful in associating the task to another record. • Universal Inbox business service has some useful methods. • CreateInboxEx – Create inbox item and associate owner, type, etc. • DeleteInboxItem – Deletes inbox item. • GetInboxItemInfo – Gets inbox item information. • UpdateInboxItemInfo – Updates inbox item information. • Many more methods to explore in both business services.

  23. SOME IMPORTANT NOTES

  24. NESTED QUERIES Avoid nested queries, whenever possible. Great performance improvement factor. Avoid any redundant queries. Include any conditions inside the while loop within the Search Expression. For instance, let’s say that the requirement is as below. Find current incident. Loop through each subject of the incident. If the person number of the subject is not null, then Check if the person number is present as a Contact Id in Incident Contact BC. If not present, create an intersection record between incident and contact, to associate the contact to the incident.

  25. NESTED QUERIES • boIncident = TheApplication().GetBusObject(“PUB HLS Incident”); • bcIncident = boIncident.GetBusComp(“PUB HLS Incident”); • bcSubject = boIncident.GetBusComp(“PUB Subject”); • bcIncidentContact = boIncident.GetBusComp(“Incident Contact”); • With (bcIncident) • { • ClearToQuery(); • SetViewMode(AllView); • SetSearchSpec(“Id”, strIncidentId); • ExecuteQuery(ForwardOnly); • if (FirstRecord()) • { • with (bcSubject) • { • ClearToQuery(); • ActivateField(“Person Number”); • SetViewMode(AllView); • SetSearchSpec(“Incident Id”, strIncidentId); • ExecuteQuery(ForwardOnly); • varisrec = FirstRecord(); • while (isrec) • { • strPersonNumber = GetFieldValue(“Person Number”); • if (strPersonNumber != “”) • { • with (bcIncidentContact) • { • ClearToQuery(); • SetViewMode(AllView); • SetSearchSpec(“Contact Id”, strPersonNumber); • ExecuteQuery(ForwardOnly); • if (!FirstRecord()) • {

  26. NESTED QUERIES • After avoiding nested and redundant queries, the script looks like this. • boIncident = TheApplication().GetBusObject(“PUB HLS Incident”); • bcSubject = boIncident.GetBusComp(“PUB Subject”); • with (bcSubject) • { • ClearToQuery(); • SetViewMode(AllView); • SetSearchSpec(“Incident Id”, strIncidentId); • SetSearchSpec(“Incident Contact Id”, “IS NULL”); • SetSearchSpec(“Person Number”, “IS NOT NULL”); • ExecuteQuery(ForwardOnly); • varisrec = FirstRecord(); • while (isrec) • { • // Create an intersection record beween Incident and Contact • isrec = NextRecord(); • } • } • Incident record is the active record, needless to query on it. • Checking if Person Number is not null, can be included in the Search Spec. • The nested query can be created as a join in PUB Subject to avoid querying inside loop. • The requirement basically gets done with a single query in the script.

  27. GLOBAL VARIABLES • Global variables should not be declared. • They would cause critical damages. • Global variable values over-ride local variable values.

  28. GLOBAL VARIABLES • Global variables should not be declared. • They would cause critical damages. • Global variable values over-ride local variable values.

  29. COUNT RECORDS FUNCTION • CountRecords() function should be avoided, whenever possible. • Using an MVL to count child records should be avoided, whenever possible. • It’s a great performance improvement factor.

  30. OUTER JOINS • Outer joins would, sometimes, be very useful in certain queries. • Nevertheless, whenever possible, outer joins should be avoided. • It’s a decent performance improvement factor.

  31. INDEXES • Fields that are used for querying should be indexed. • Foreign key columns, especially, should be indexed. • It’s a great performance improvement factor.

  32. MULTI VALUE LINK • Make sure to have the Primary ID field in the MVL. • Performance could be nasty without a Primary ID field. • It’s a great performance improvement factor.

  33. FORCE ACTIVATING FIELDS • Whenever possible, avoid setting Force Active property to TRUE at field level. • Whenever possible, avoid setting Link Specification property to TRUE at field level. • These are decent performance improvement factors.

  34. MODIFYING CLOB COLUMN • When a CLOB column is created, it cannot be modified for altering size. • The only way to alter size of the CLOB column is as follows. • Delete the CLOB column from physical database table. • Recreate the CLOB column again at Siebel tools with desired size. • Important Note: • The above process is devastating for an Oracle database. • In case of Oracle database, the size of a CLOB column should never be changed. • Siebel sets it to 131 K by default, and it should not be altered. • Altering it will create issues in generating a new database template file.

  35. NON TRANSACTIONAL TBUI Non-transactional TBUI instantly commits the task data to the database. This shows a smoother and flawless navigation between task views. This is a great performance improvement factor.

  36. SORT SPECIFICATIONS Whenever possible, avoid sort specification directly at BC level. Make sure the sorted fields are indexed. These are great performance improvement factors.

  37. MODULARIZATION OF CODE Make sure that a big script is modularized. Benefits are It increases the readability. It makes sure that the main script page does not exceed 16K size.

  38. CODE IN PRECANINVOKEMETHOD EVENT OF APPLET Whenever possible, avoid code in PreCanInvokeMethod event of Applet. Instead configure Applet user properties.

  39. RE-USABLE CODE At times, multiple applets might be holding the same piece of code. Better have a business service as a single source. This single source would be called from any number of applets. Benefits are Reduces un-necessary code at applet level Any changes to the script in future needs to be done only once as the code is centralized in a business service.

  40. BROWSER SCRIPT Do not write server script in the browser script. Instead execute it either from applet server script of business service server script. This is a very good performance improvement factor.

  41. NULL QUERIES Avoid the situation of getting into blank queries, which could fetch millions of records. Any field used in the search specification should be checked to see a presence of value. If no value is present, the query should not be executed. This could possibly avoid Fetching numerous records from the database. Incorrect execute of the code. This is a great performance improvement factor.

  42. TRY CATCH AND FINALLY Encapsulate your code between try and catch. This makes sure that a technical error is thrown and caught appropriately. Make sure to destruct objects in FINALLY in the sequence of BC and BO respectively. If there are no objects to be destructed, avoid using finally block.

  43. HARD-CODING OF VALUES Avoid hard-coding of values in the script, whenever possible. Instead maintain them in the list of values, as they could be fetched run-time. Messages in server script can be stored as message categories. If it is not a multi-lingual implementation, the following is applicable. 1) Messages in browser script do not require message categories. 2) Messages in workflow do not require message categories.

  44. REDUNDANT CODE Any commented code should be removed. This increases the look N feel of the script. This increases the readability of the script.

  45. SWITCH CASE Use switch / Case instead of multiple IF statements. Increases the readability of the script. This is especially required in all the events of BC level.

  46. WITH STATEMENT Increases the readability of the script. Not a performance factor whatsoever.

  47. HEADER BLOCK AND INLINE COMMENTS Header block should indicate the author, description and other salient features of code There should be inline commenting to describe the special logics involved in script.

  48. RETURN STATEMENT Makes sense to have a single return statement at the END of the code. However, it may not be possible to strictly follow this. DO NOT have return statement inside finally block, it’s fatal.

  49. INDENTATION OF THE CODE Indentation should be properly followed while writing a script. This increases the readability of the script.

  50. FORMATTING OF THE SCRIPT Extra white spaces should be removed from the script. Alignment is one important factor of formatting.

More Related