Oracle has done an outstanding job converting Classic Self-service to Fluid to promote the modern, mobile user experience. But what about back-office functionality? We certainly can't predict the future, but it seems that back-office transactions will remain Classic for a very long time. Rather than change the appearance of the back-office user experience, I believe our best strategy is to build back-office, business process-based navigation. Our users don't seem excited about the NavBar and Navigator and we can nearly eliminate its use through properly constructed business process based navigation. Here are a couple of business process based navigation tools:
- Navigation Collections
- Master Detail
- Dashboards
- Activity Guides
- WorkCenters
Because of its simplicity and ease of maintenance, we often recommend customers start with Tile Wizard-based Navigation Collections. Oracle, on the other hand, is providing business process based navigation by converting Classic WorkCenters to Fluid WorkCenters.
In a recent attempt to provide a segue from one business process to another, I added a Fluid WorkCenter to a Navigation Collection. Both a Tile Wizard-based Navigation Collection and a Fluid WorkCenter contain a left-hand sidebar. Embedding one in another creates a Left-panel Collision. To avoid this collision, I marked the Navigation Collection item Replace Window property. Unfortunately, trying to launch the Fluid WorkCenter from a Navigation Collection generated an SQL error. This prompted me to try launching the Fluid WorkCenter outside the Navigation Collection. To my surprise, this also generated an SQL error. The WorkCenter worked before adding it to a WorkCenter, so this was clearly unexpected. After reviewing the app server log, I discovered a single-row subquery within the Fluid WorkCenter framework was returning more than one row. It didn't do this before adding the Fluid WorkCenter to a Navigation Collection, so what changed? One thing: I added a Fluid WorkCenter to a Navigation Collection. The SQL that caused the problem looks for any CREF that uses the WorkCenter's target component and is marked as a Fluid Workcenter (contains &FLWC=Y in the CREF additional parameters). By adding a Fluid WorkCenter CREF to a Navigation Collection, I created a CREF Link to the original CREF. The end result was a second matching row in the portal registry table (PSPRSMDEF).
Lesson learned: Don't add a Fluid WorkCenter to a Navigation Collection or any other structure that will result in a second CREF with the same (or similar) target. This makes sense because Fluid WorkCenters are business process-based navigation. Adding business process-based navigation to business process-based navigation may not make sense.
Is there a workaround? Absolutely! Instead of adding the Fluid WorkCenter directly to a Navigation Collection, create a redirect iScript. The PeopleCode in the iScript will send the user to the existing Fluid WorkCenter content reference rather than duplicating the existing content reference in the Navigation Collection.
Is the workaround worth the effort? That is an entirely different question. First, the effort is minimal and will require just a few lines of PeopleCode and a Permission List update. But what is the savings and user experience impact? Fluid WorkCenters are designed to be launched as homepage tiles. To launch a homepage tile, you must be on a homepage. The user savings, therefore, is the user won't have to return to a homepage to launch the next business process but can transfer directly from one to the next. Returning to the prior business process is as simple as clicking the Fluid header back button.
Configuring productive Business Process navigation is critical to successful Fluid implementation. Are you ready to learn more? Register now for our Fluid 1 course online. Do you have a whole team to train? Contact us for group pricing and delivery options.
