ADF Fusion web Applications and WebCenter Portal applications are two different types of applications. Although WebCenter Portal is based upon ADF it works a little different than a regular fusion web application.
For instance it is a good practice to separate the development of your portal and your taskflows. The reason for this is that you can reuse the taskflows in other portals or you can easily plug them into WebCenter Spaces.
When you are building a portal, you probably have to write some transactional taskflows that will connect to a custom database. A portal is not just about collaborative services or integrating external applications. Most of the time you have to build some functionality and include it into the portal.
Because WebCenter is using ADF, it is a wise decision to build those functionalities with ADF Business Components as your data layer.
When building Business Components for a portal there are a few best practices that I would like to recommend. They help to minimize the integration effort and maximize the reusability of your components which is one of the key features of a proper designed portal.
When configuring your business component application module you can choose to use a JDBC URL or DataSource. A JDBC URL is the database configured in the application resources. This means that the connection of the database is a part of your application. A data source is configured in the application server. You only pass the name of the data source to the AM and this will use a JNDI lookup to get the connection pool to the database.
In order to configure the AM you have to right click on your AM and select Configuration.
Click on the Edit button to open the configuration:
Make sure the Data source name matches the data source you create in WebLogic:
The advantage of this is that the information about the connection is not stored in your application. This means that you do not need to change your deployment profile when you want to deploy to a different environment and you want to connect to a different database.
When using WebCenter Spaces, this is the only way of doing. Adding custom taskflows is to WebCenter Spaces is by using the extension project. Because this project is more a library than a real application, the database connection will not be available to Spaces so you can only use the data source.
So once again, when using this technique, you ensure that your taskflow will work in both WebCenter Spaces and WebCenter Portal.
I would also recommend the previous tip for any regular fusion web application. This tip however, I will only recommend to portal development. The reason for this is that in essence, taskflows in WebCenter have a slightly different concept than in a fusion web application. The technique for building them is the same but taskflows in a fusion web app is more to reuse and divide the application in modules.
In WebCenter however, taskflows are more building blocks for your portal that you want to make available to business users and administrators so they can build their own portal and pages.
By default when you create a taskflow and use data controls, it will automatically use a single data control session and transaction and share this over all your taskflows in the application. This means that if you are referring a VO on one page and referring the same VO on another page, they will share the same data, same state, same parameters (if you are using view criteria) and so on.
This makes perfectly sense for a fusion web application but for a Portal application you often want to create a transaction per instance of taskflow and definitely want to allow each taskflow to have their own parameters in a view criteria.
This can be configured in the behaviour tab in the overview of the taskflow. Just uncheck the Share data controls with calling task flow.
In order to allow a new transaction for each instance you need to select Always Begin new transaction in the drop down list above as shown in this screenshot:
This will completely separate each instance of your taskflow and data control transaction.
From a portal perspective, this is one of the most important tips I can give. One of the main concepts of portals is interoperability. This means that you develop your components in such a way so they can communicate with other components that you do not control.
If you are building a taskflow that shows an overview of the departments and you allow the user to select a department for editing than you might end up building your taskflow with no input parameters. In the end there are no requirements so why bother?
Once again, in a fusion web application this makes perfect sense while in a portal this is a common mistake. A portal is not just a group of silo applications. It should also make the available parameters and event available to wire those silo application together so your portal gets aware of the context.
If you also have to build an integration with the CRM or ERP or any other backend system and you can also select the department in that integration. Why not just link both components together by exposing events and parameters. This would mean that if you select a department in your department overview taskflow, it can pass the selected department to the CRM integration to immediately show the sales result of the department while another taskflow can show an overview of the ongoing projects with their progress.
Can you see what added value this gives? From a development perspective it doesn't require any much effort but it can provide the user with such a better user experience that is required from a modern portal.
In order to achieve this we have a few techniques that can help us with this.
From a business components perspective I would recommend using view criteria in order to support input parameters. One thing to keep in mind is to provide default behaviour when no parameters are provided so if you are building an edit form, show an overview in case the input parameters are not provided. This can be easily achieved by using a router in the taskflow:
In order to pass values to the portal we will be using contextual events. Because this is quite a large topics and not easily explained in a paragraph, I will dedicate another blog post about this and show how to use contextual events to pass events and parameters from a taskflow to another taskflow or portlet.
In the end, when developing taskflows for WebCenter keep in mind that the concepts are slightly different than when developing a fusion web application.
A fusion web application is a closed application that you fully control. You normally get the requirements from A to Z while a portal is more open.
When developing a portal, you build the building blocks but you do not build the actual application. This is the responsibility of the business users and content owners. Because of this you need to provide them with flexibility and keep in mind that you do not know everything about the environment so everything needs to be more flexible.