Best Practices from Oracle Development's A‑Team

How to Get Mobile Access to WebCenter Portal Activity Stream


Oracle WebCenter Portal (WCP) provides the activity stream for a portal via a Representational State Transfer (REST) interface. This article describes accessing this activity stream from a mobile device, making use of the Oracle Service Bus (SB), and the Oracle Mobile Application Framework (MAF). The WCP activities are persisted on the mobile device using the A-Team Mobile Persistence Extension for Oracle MAF, and status updates can be posted to WCP with the option of including location information from the device.

More information about the persistence extension is available in the blog post: A-Team Mobile Persistence Extension for Oracle MAF.

Main Article

This article describes the flow of information about activities from WCP, out through SB, to a mobile device.  Additionally, status update messages can be sent from the mobile device back through SB and be posted to WCP.  These messages from the device can optionally include device location information, allowing other users to see where the mobile device was when the message was sent.

WCP Activity Stream

WCP tracks what users do and makes information about those activities available via an Activity Stream feature.  Activity Stream captures changes to Documents (including wikis and blogs), Announcements, Discussions, Page activities, and People Connections.  The actions tracked can be the activities of a user's connections, actions taken in portals, and business activities.

This is a sample of an Activity Stream viewed in WCP:

WCP Activities

WCP REST Interface

The activity stream is published through the People Connections REST API. This is a documented REST interface that includes all of the attributes of an activity, such as the activity type and created date.

SB Business Service

In SB, a REST binding represents the business service, and is shown on the right side of the screen in the External Service column. This is where the REST binding information is entered, pointing to the WCP REST interface.  For WCP, the base URI of the REST binding would be:


Then, the resource path would be:


Note that portalGuid is in parentheses, indicating a parameter that will be populated when the REST call is made.

Lastly, an operation binding is created for that resource path. The request schema URL can be left blank, since it will be populated when the REST service is exposed. The response schema URL, however, needs to be created.  SB offers a tool to create the schema from a sample. The easiest way to create the schema is to use a REST tool like Postman and capture the result when the WCP REST API is invoked.  This result can be pasted into the SB tool as a sample and SB creates the schema from there.  This process can be repeated for whichever WCP REST APIs are needed.

SB Proxy Service

Once the business service REST bindings are created, the business service can be exposed as REST.  In SB, this creates a REST technology icon on the left side of the diagram in the Proxy Services column.  This is the REST interface that SB exposes to clients.  As before, resource paths and operation bindings are created, but these entries can be simplified to meet the needs of the SB clients.  The goal of this interface is to provide just the information that is needed, and in a format that is customized to meet the client's requirements.

The WCP REST activity stream response, for example, includes several sets of links.  If the SB client doesn't need or want those links, then the OSB proxy service schema would simply leave out the links.

The SB proxy service schema can be created from a sample provided by the client or defined from scratch. The SB pipeline handles the translation from the business service elements to the proxy service elements, populating the proxy service schema elements use Replace operations on the Response action.

The path through SB would look something like this:


For the WCP activity stream application, these are the SB proxy service REST bindings:


Note that the messageBoard entry is used for posting status update messages back to WCP.


Mobile Application Framework Extension

Now that the SB REST interface is defined, the application on the mobile device can use that interface.  Both MAF and A-Team Mobile Persistence Extension need to be configured in JDeveloper.  This allows the creation of a MAF application and ViewController project, that can be deployed to either a mobile device or an emulator.  Creating the MAF application is accomplished by stepping through the JDeveloper wizard.

A-Team Mobile Persistence Extension for Oracle MAF

The A-Team Mobile Persistence Extension for Oracle MAF provides wizards to facilitate creating a persistence mechanism on the mobile device, using the on-device SQLite database.  This on-device persistence allows working in offline mode then synchronizing when back online.  To generate the persistence artifacts, run the MAF Business Objects from REST Web Service wizard provided by the A-Team Mobile Persistence Extension for Oracle MAF.  For the REST service connection, choose the OSB instance defined above.  Only enter the host:port and endpoint URI that is configured in the transport of the SB proxy service.

For the resources in the wizard, enter the resource paths that were defined in the SB proxy service REST bindings.  Assuming that the SB application is deployed and running, the wizard accesses the REST interface and captures the results.  The wizard presents the classes that can be persisted. For the persisted classes, the attributes can be modified and at least one attribute must be identified as the key.  The wizard then presents screens to define parent-child relationships and Create, Read, Update, Delete (CRUD) operations.

When the wizard completes, there will be generated model and service classes, plus other configuration entries to allow persisting the data provided by the OSB REST interface.  The model service classes can then be exposed as data controls.

For the WCP activity stream data, the following model classes and data controls were created:

  • Portal and PortalService: persisting the list of all portals, as returned by the /portal REST resource.
  • Activity and ActivityService: persisting the activities for a particular portal, as returned by the /portals/{portalGuid}/activities REST resource.
  • Person and PersonService: persisting the details about a user, as returned by the /people/{personGuid}/details REST resource.

Mobile Application

Now that data controls are available, a feature and task flow can be created by editing the maf-feature.xml file.  For this activity stream application, a single task flow was created that started with a list of portals, defined as PortalList.amx. Selecting a portal then navigated to a page listing the activities for a portal, defined as Portal.amx.  Selecting an activity navigated to the activity page listing details about the activity, the author, and the activity's location, defined as Activity.amx.  On the portal page, a secondary menu popup was added to navigate to the send message page, defined as SendMessage.amx.

The task flow looks like this:


All of this was done using the MAF AMX components made available via the Mobile Application Framework Extension.  The mobile application is available for download here: Activity_mobile.zip

The portal list on the mobile device looks like this:


When sending a status update message, and additional button was added to send the message with location information from the device.  This retrieved the current location from the device, and attached the latitude and longitude to the outgoing update message.  On the activity details page, code was added to parse the location information, if any, and call out to an address-lookup service.  This allowed the activity details page to show the street address of where the status update message was sent.


The combination of WebCenter Portal, Service Bus, Mobile Application Framework, and A-Team Mobile Persistence Extension creates a compelling mobile application solution.  As this post has demonstrated, portal artifacts can be translated into a simplified interface that can be consumed and persisted on a mobile device.


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content