slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES PowerPoint Presentation
Download Presentation
TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES

Loading in 2 Seconds...

play fullscreen
1 / 51

TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES - PowerPoint PPT Presentation


  • 118 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'TASK FLOW FUNCTIONALITIES SIEBEL BEST PRACTICES' - bryga


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

TOPICS

TASK FLOW FUNCTIONALITIES

SIEBEL BEST PRACTICES

slide2

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.

slide3

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.

slide5

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.
slide6

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.

slide8

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.

slide9

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).

slide10

MAINTAINING THE CONTEXT OF THE TASK VIEW

Notice the Task Step Context configured for the task view.

slide11

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.

slide12

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.

slide13

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>

slide14

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.

slide15

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.

slide16

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.

slide17

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.

slide18

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.
slide19

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.
slide20

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.
slide21

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.

slide22

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.
slide24

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.

slide25

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())
  • {
slide26

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.
slide27

GLOBAL VARIABLES

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

GLOBAL VARIABLES

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

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.
slide30

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.
slide31

INDEXES

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

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.
slide33

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.
slide34

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.
slide35

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.

slide36

SORT SPECIFICATIONS

Whenever possible, avoid sort specification directly at BC level.

Make sure the sorted fields are indexed.

These are great performance improvement factors.

slide37

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.

slide38

CODE IN PRECANINVOKEMETHOD EVENT OF APPLET

Whenever possible, avoid code in PreCanInvokeMethod event of Applet.

Instead configure Applet user properties.

slide39

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.

slide40

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.

slide41

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.

slide42

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.

slide43

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.

slide44

REDUNDANT CODE

Any commented code should be removed.

This increases the look N feel of the script.

This increases the readability of the script.

slide45

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.

slide46

WITH STATEMENT

Increases the readability of the script.

Not a performance factor whatsoever.

slide47

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.

slide48

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.

slide49

INDENTATION OF THE CODE

Indentation should be properly followed while writing a script.

This increases the readability of the script.

slide50

FORMATTING OF THE SCRIPT

Extra white spaces should be removed from the script.

Alignment is one important factor of formatting.