Have you ever thought of a system that understands your needs, collects information effortlessly, and lets you make decisions without locking in data immediately?
Introducing Transactional Task-Based UI (TBUI) – a game-changer approach to data handling in guided flows. Whether you’re building a client profile or crafting dynamic apps, TBUI provides the control and adaptability you need. Let’s see how TBUI can take your data management to the next level!
Why Transactional TBUI?
Task-Based UI (TBUI) guided flows are designed to be transactional by default. This means that any data collected or modified during the execution of a task is temporary and exists only for the duration of the task unless explicitly committed to the database.
Figure 1 Defalut task setting
Think of a task, or “guided flow,” as a question-and-answer session, something similar to an insurance agent building a profile for a policyholder. An answer to one question may prompt additional follow-up questions. Until all queries have been asked and answered, no conclusions can be drawn. The transactional nature of a task enables the collection of a complete set of information before making a decision to commit or modify data in the database. During this process, the data is stored in temporary or “shadow” storage while the task is active. You can even pause the task and resume it later; the data will be revived but not yet committed to the database. If the task is canceled, the temporary data gathered is discarded. This approach offers great flexibility in handling data during a task’s execution and is one of the core principles behind the concept of tasks.
How does it work?
A task typically uses a Transactional Business Component (TBC) to temporarily store the data entered. When data is entered into an Applet (which is also supported by a TBC), it’s transferred from the Applet’s TBC to the task’s TBC using a Siebel Operation Step. This process enables the collection of data across multiple Views.
Figure 2 This is an example of a TBC used in a task.
How the data is committed to the database?
Tasks offer a great deal of flexibility in how the data can be committed to the database. Because tasks are transactional, you must explicitly specify where the data should be saved. Standard Business Components (SBCs), such as Account, Contact, and Action Business Components, handle this process. To transfer data from a TBC to an SBC, you can use the output arguments of various step types, including View Steps, Business Service Steps, and Siebel Operation Steps. For example, to retrieve data from a TBC and load it into an SBC, you might configure a Business Service Step as illustrated in the figure below.
Figure 3 One of the ways to retrieve data from a TBC and load it into a SBC.
Once data is loaded into a SBC, there are three ways to commit it:
- Using a Commit step: This explicitly commits any data updated in any SBCs in the Task. Use this when you want to commit the data immediately.
Figure 4 A commit step.
- When the Task ends the data is automatically committed.
- Using the Immediate Commit in Task Business Component User Property: This commits the data immediately. Note that if you set this to TRUE, the transactional nature of the Task becomes ineffective even if the Transactional flag is set to TRUE. You can use this setting to override the Task’s Transactional settings at the Business Component level.
Try transactional Tasks Today
Now that you understand the transactional nature of tasks, try using TBUI to guide your users through their next repetitive task. Leverage the transactional capabilities of tasks to efficiently gather critical data. If you need any assistance, feel free to reach out to us!