• When to Use Concurrent Processing
• Overview
• Common UI Flows
• Work Area Overview or Dashboard Region
• Decision Tables
• Handling Errors
• Concurrent Process Free Reusable UIs
• Frequently Asked Questions

There are two common use cases that require using concurrent processes:

• Scheduled action: Users need to perform an action based on a predetermined schedule. For example, users can set up an antivirus program to run every day at midnight on their computers, or a payroll clerk can set up a program to run the payroll twice a month.


• Time-consuming action: Users perform an action that could take a long time to finish. Using the concurrent process technology, this action can be performed in the background so that users do not have to wait for it to finish before doing their other work. For example, billing specialists may want to reconcile 100 invoices after they have finished creating them. This process can take up to five minutes, so the reconciliation should happen in the background, enabling users to continue with their other work.

  The same process can be run online or concurrently in the background. Online means that the process is being run in real-time. The application shows a modal processing message dialog box, and users have to wait for the process to complete before they can continue with their work.

  As the product designer, you must judge when it's appropriate to make users wait for the results versus running the process in the background. If a process takes more than a few seconds, and it is not critical for users to be able to go to their next tasks, use concurrent processing technology to run the process in the background. Usually, actions on a single object run online, but actions on a group or batch of objects should be run in the background. You can use the information in the following table as a general guideline.

A work area is the complete set of tasks, reports, business intelligence, searches, and other content that users need to accomplish the tasks associated with a business goal. All processes relevant to a work area should be accessible. Users should not need to go to the central Schedule Processes work area to start these tasks. You should create a concurrent process as a regular business task with in-context feedback to show the progress of the process.

Figure 1. How a concurrent process can be used in a work area

Starting a Process

Your users are scheduling a task or performing a task, not running a process. Treat the process as you would any other task. Any button or link within the work area can start a concurrent process. Some common access points are:

• Table actions, page actions, or region actions
• Checklists
• Task panes

Terminology
Concurrent processing is a technological term used internally at Oracle. Users are concerned only about performing their tasks and achieving their business goals. Avoid using generic terms like process and run to describe these user tasks. Instead, use verbs and nouns that describe the exact business process that users are accomplishing.

Monitoring Processes

In Oracle Fusion, users should not need to go to a central Scheduled Processes work area and search for their processes. They should be able to get 80 percent of the information that they need directly in their work areas. The user interface (UI) displays monitoring information in four common ways (see examples in the Common UI Flows section of this guideline):

• On the Work Area Overview page or a dashboard
• On the page where users took the action
• On the page where users would expect to see the results of the action
• Through notifications

Feedback
Once users have successfully started a concurrent process, they need feedback to confirm that the process has started. The result of the action should be clearly visible on the page, for example, by having the processing status changes from Unprocessed to Processing. If the processing status is not clearly visible on the resulting page, provide a confirmation message. The technology provides a standard confirmation message, but this message may not be sufficient for your purposes because the information about status does not persist.

Notifications
Consider using notifications for processes if users need to know that a particular process is finished or contains an error.

Monitoring Messages
Common status messages are provided by the Concurrent Manager. To save screen real estate, you can use only the icons (with the appropriate Alt text on hover). An extended definition of each status is provided in the technology documentation.

Status in the UI	Internal ESS Status
Not Started (Scheduled for later)	WAIT
Not Started	BLOCKED READY PENDING VALIDATION
On Hold	HOLD
Canceled	CANCELLED CANCELLING
Processing	RUNNING PAUSED COMPLETED
Completed Successfully	SUCCEEDED FINISHED
Completed with Errors	ERROR VALIDATION FAILED
Completed with Warnings	WARNING
Expired	EXPIRED
Schedule Ended	SCHEDULE ENDED

Any link or button in the UI can start a concurrent process provided that users are given some feedback to let them know that the action is taking place in the background. The following sections describe some common UI flows.

Table Actions
If users need to perform an action on an object in a table, show the concurrent process as a table action. Enable users to select multiple rows and perform this action whenever applicable. For example, users can select multiple invoices to reconcile them. The back end starts a concurrent program, but this program is transparent to users. The progress of the reconciliation process appears in a dedicated column.

Figure 2. Reconciling multiple invoices

Figure 3. Status of the reconciliation process

Page Actions

If the action is performed on the entire object represented on the page, use a page level action to start the concurrent process. This is usually a final action that brings users back to a manage page.

Figure 4. Posting a journal

Figure 5. Status of posting journal

Region-Level Actions

If the action is performed on the data within a page subheader or a page region, use a region-level action to start the process. While the data in the region is being processed, it is not available to users. Users can continue to do other tasks on the page.

Figure 6. Refreshing the data in a region

Figure 7. The data is refreshing

Using the Checklist Pattern

You can leverage this pattern in Oracle Fusion setup flows, but it can be used anywhere that a setup task checklist is appropriate. Make sure that the Status column displays the status of the concurrent process.

Figure 8. Selecting the Install new version task from the Application Installer checklist

Figure 9. Submitting the Install new version task

Figure 10. Status of the Install new verion task

Tasks Pane

Starting concurrent processes directly from the task pane is not the best design practice because most processes require some parameters or context in which they are run. Avoid this design unless the task really does start from the beginning. For more information, see the Task Pane Guidelines.

If users start a process from the task pane, the process should navigate them to a result page. The result page is usually where users would expect to see the results of the process or the Work Area Overview page.

Figure 11. How a concurrent process can be used in the Task pane

Some use cases contain a work area or dashboard region that is specifically designed to enable users to monitor and start processes.

For example, you can use a business process-specific portlet when there is one important process that drives the work area. The payroll dashboard, for example, can show the most recent payroll run for each subunit within the organization. Technically, the processes are grouped by the parameters. This grouping logically represents the business process.

Figure 12. Payroll Calculations business process portlet in the Payroll dashboard

Allowing Users to Select Between Online and Background Processing

In most cases, the system should decide whether or not to run the process in the background or online. In some cases, however, professional users can make this choice.

If all user actions are usually processed as a batch at night, but there is a business case where users need to process one object immediately without waiting for the nightly process, make sure that the user profile is technically advanced enough to understand the difference between online and background processing. For example, a receivables specialist may create multiple receipts during the day, which are processed at night to apply the payments to invoices. In most cases, this lag time is acceptable, but if a critical payment needs to be applied immediately so that an order can be shipped, then the specialist should be able to have this receipt processed immediately.

In figure 13, the specialist can select the Apply cash immediately check box to have the process run online.

Figure 13. Choosing to run a process online

The following tables help you decide when and how to use the patterns previously described.

Use this table to help you decide where to place a launch point for a process.

Use this table to help you decide where to show monitoring information based on the launch point.

Concurrent processes can fail for various reasons. These errors should be reported to users clearly and must include all of the details required to correct the errors and rerun the process.

Notifying Users That an Error Has Occurred

Show the processes with errors on the corresponding Work Area Overview page, using a notification or the Watchlist.

Error Management UI

If an action cannot be completed because of processing errors, provide a single page for users that enables them to fix all the errors and rerun the process. If the process was run against multiple objects, create a UI that displays the objects with errors in a master table and the information that needs to be corrected in the details table.

If the process was run against one big object (for example, Post Journal), show users the entire object context and highlight the areas that have errors. Users can drill into the object, correct errors, and try to rerun the process.

Configuring a Concurrent Process

Once users click an action that starts a process, they may need to provide additional details for that process. The Concurrent Manager provides these reusable UIs. If additional details are not required, do not display this UI. As a product designer, you can decide to show all four tabs or hide the ones that you don't need.

Reports: If users are scheduling reports, they may end up using the Business Intelligence Publisher scheduling UI instead of the concurrent process submission UI.

If there is no need for users to enter additional parameters, skip the Parameters UI in the concurrent process submission UI.

Note that the Concurrent Manager content is within a container that is produced by the product team. The buttons in the dialog box layout are not placed at the bottom of the dialog box (as is typical). This placement is not possible in the current framework. Also ensure that the page or dialog box name is consistent with the action that users selected in the previous UI.

There are two modes to the submission UI: advanced and basic. Both are provided by the Concurrent Manager team.

Figure 14. The Basic Submission UI

Figure 15. The Advanced Submission UI

Parameters

Purpose: This section is flow or product specific. If you need additional input from users, use this section. If there are no parameters, then do not show this tab.
Who will design: The product team needs to define this content.

Schedule

Purpose: This section enables users to schedule a process to start at a later time or to schedule a recurring process. The schedule is set to As Soon As Possible by default.
Who will design: The Concurrent Manager team provides this content.

Output

Purpose: Use this section if the process generates a report. This section enables users to pick the report templates and report delivery options (email, fax, and so on). Nothing is selected by default.
Who will design: The Concurrent Manager team provides this content.

Notification

Purpose: This section enables users to decide who needs to be notified about this process. Users can select recipients and whether to notify them when the process ends successfully or if it fails. No notifications are selected by default.
Who will design: Provided by Concurrent Manager team.

Process Options

Purpose: This dialog box enables users to override certain settings, such as language, number formatting, or time zone, only for this scheduled process. This dialog box is always available to users.
Who will design: The Concurrent Manager team provides this content.

Work Area Monitoring Region

You may have use cases where your users need to keep track of multiple concurrent processes and their statuses. The Concurrent Manager team provides a task flow that can be inserted into a region within your Work Area Overview page. You must determine, at design time, what processes are monitored here. You also select the name of the region.

Figure 16. The Concurrent Processes monitoring region in a work area

Central Scheduled Processes Work Area

A central scheduled processes work area is provided for users who need to monitor the progress of processes across business domains. These are usually roles such as system administrators, functional analysts, and so on. When users view this page, their current work area is closed, and they lose all context. Design work areas so that users can get all their work done in context. Regular business users should never need to view this page.

The goal of this work area is to provide administrative users with the tools that they require to perform all Oracle Fusion maintenance.

1. What about reports? What is the difference between the Process Monitoring tool and the Reporting and Analysis tool?

For more information, see the Reporting Guidelines.

2. My concurrent processes do not fit into a work area or a dashboard. Where do I show the processes?

All processes are run to achieve a certain business goal. Find the work area that is dedicated to the business goal, and include links to your processes from there. If you think about your information architecture and include these tasks in the correct place, they are easier for your users to find and use.

3. Is there a central launch point or Schedule Request page as there was in legacy applications?

Yes. This point is called the scheduled processes work area and is referred to throughout this document.