You are here:

Section - 1 : Mobile Output Process

Mobile output generation, like all other output formats, may occur on demand or in a batch process. Part of the document automation team's role is to work with a cross-functional team to determine how your company will make mobile output from Documaker available to your customers. We will explore possible work flows for mobile output management for both on demand document access and generation as well as batch creation for access.

Regardless of the delivery methodology, secure access to mobile content must be established through your existing customer access systems. Generally this means that the customer would login to your company's web portal to gain access to mobile content. The web portal is therefore responsible for managing client identification and client profile information including the customer's content delivery preferences and authorization for web content delivery. If your company does not already have a web portal strategy in place Oracle has a WebCenter product that can be considered.

The scenarios provided below offer possible options for mobile delivery that may suit the needs of your requirements. These scenarios cover the basic flow of request, processing, and presentation; however, there may be additional considerations such as transformation or filtering of the generated content.

Scenario 1 - Real Time Generation and Display

In this scenario the system creates mobile output and returns it to the user at the time of request. In this case the output is created at the point in time when the customer wants access to the output.

Customer requests access to a mobile document via portal or online application
The Portal or application request with the available data is routed to Documaker
Documaker returns the personalized content to targeted location and provides feedback to calling application
Portal or application streams the content to the customer

This methodology is suitable for situations where a defined set of customer data has already been processed in a prior Documaker request. For example, your system generates monthly billing statements that have historically been mailed to the customer. The customer typically receives a monthly statement in the mail and has not signed up for electronic delivery. However, they now are online, logged in to your company portal, and wish to view last month's statement electronically. In a traditional PC browser they could view a generated PDF (assuming one was created when the paper statement was generated); however, you wish to provide them with a richer mobile experience on their mobile device. To support this effort, the company portal can provide an option that will allow the user to view their prior month's statement in mobile form. The web portal must be able to identify the transaction identifier for the content to be delivered to the end user. The portal would be responsible for sending a web service request with that identifier to Documaker's doPublishFromFactory web service method and for processing the response. Using values returned in the doPublishFromFactory and doGetPublishingInfo web services response, the portal would then call doGetPublishingInfo using the Heavy setting to return the mobile output in the response so that it can be streamed back to the user's device. For more information on configuring the doPublishFromImport and doGetPublishingInfo web services to respond with the needed output, see the Documaker Enterprise Edition Administration’s Guide topic "Using Documaker Web Services".

Note that this method assumes the content can be rendered independently of other files or that the files are contained/referenced elsewhere. The doPublishFromImport response only contains the mobile output contents.

Scenario 2 - Repurpose and Display

In this scenario the system creates mobile output from previously processed data and returns it to the user at the time requested. In this case the data necessary for the output was used in advance of the customer's request for generation and delivery in a non-mobile format. The prior request is repurposed to create the mobile output.

Back office system routes a request with data to Documaker
Documaker generates and delivers content
1. Customer locates prior transaction/activity through the portal or application and requests access to a mobile document
2. System locates prior request and requests mobile output
3. Documaker uses the prior request to generate personalized content
4. System streams the content to the customer

This methodology is suitable for situations where a defined set of customer data has already been processed in a prior Documaker request. For example, your system generates monthly billing statements that have historically been mailed to the customer. The customer typically receives a monthly statement in the mail and has not signed up for electronic delivery. However, they now are online, logged in to your company portal, and wish to view last month's statement electronically. In a traditional PC browser they could view a generated PDF (assuming one was created when the paper statement was generated); however, you wish to provide them with a richer mobile experience on their mobile device. To support this effort, the company portal can provide an option that will allow the user to view their prior month's statement in mobile form. The web portal must be able to identify the transaction identifier for the content to be delivered to the end user. The portal would be responsible for sending a web service request with that identifier to Documaker's doPublishFromFactory web service method and for processing the response. Using values returned in the doPublishFromFactory and doGetPublishingInfo web services response, the portal would then call doGetPublishingInfo using the heavy setting to return the mobile output in the response so that it can be streamed back to the user's device. For more information on configuring the doPublishFromFactory web service to respond with the needed output, see the Documaker Enterprise Edition Administration’s Guide topic "Documaker Web Services".

This methodology is suitable for situations where you will not generate mobile output in advance but have created the output in a traditional format. In this scenario mobile output is generated based on a request, either on demand or scheduled batch and the output is retained within the Documaker processing tables. Documaker only retains prior requests for a temporary period established by your corporate guidelines and configured with the Historian tasks. The application that generated the request must know the correct index information to locate the content, allowing the portal to provide a direct link to the staged content and the portal is also responsible for managing access to that link. While it is always possible to reference an invalid link in other Use Cases noted, it is important to consider accessing the links back to the Documaker processing tables during temporary storage.

Scenario 3 - Archive and Display

In this scenario the system creates mobile output during a scheduled process, archives it in a repository, and returns it to the user at the time requested. In this case the data necessary for the output was used in advance of the customer's request display to generate the content and stage it for future display.

Back office system routes a request with data to Documaker
Documaker generates and stores the mobile content into a repository (e.g. WebCenter Content)
1. Customer requests access to a mobile document
2. System locates stored content in the repository
3. System streams the content to the customer

This methodology is suitable for situations where a defined set of customer data is to be processed in advance of its access and use. For example, you may wish to prepare periodic statements for customers that have opted-in to electronic delivery. A customer's monthly banking statement for example where the data is generated on a scheduled basis, processed by Documaker, and stored in a content management system for later access. In this case, a customer may receive a notification that their statement is available (see scenario 4) or happens to log in to your customer portal and can access the content there. In this case the customer selects a link presented in the portal which ties back to the content repository. The content repository returns the content and the web portal would then be responsible for transformation (if needed) and presentation to the customer.

In this scenario Documaker is not invoked at the time of delivery. This scenario differs from scenario 2 in that the mobile content is pre-created and stored in a repository for eventual delivery.

Scenario 4 - Mail Notification and Delivery

In this scenario the system creates mobile output during a scheduled or on demand request and delivers it via email. In this case the output is pushed to the user.

Back office system routes a request with data to Documaker
Documaker generates the mobile content
Documaker attaches the content to an email and delivers it to the customer

This methodology is suitable for situations where the mobile content should be delivered via email and is generated while the user is not waiting for the request. For example - a personalized notification to complete forms online for the customer (patient's) upcoming appointment. On a scheduled basis, content from the originating application would be sent to Documaker, Documaker would process the data to create mobile output and then generate an email with that content to send to the intended recipient. In this use case, it is important that sensitive information be sent in a secure fashion or not sent at all. With this scenario, it is also important to keep in mind the limitations of mail clients to view certain file types and perform certain transformations. As always, be sure to validate that your mobile output displays appropriate for your intended mobile devices.

Additional Considerations

The Scenarios "Repurpose and Display" and "Archive and Display", require the calling application to have some identifying information linking the previously generated data or previously processed output. There are two possible ways for the calling application to have this information:

Documaker returns a unique identifier to the calling application when the original request to process the data is made.
The calling application provides a unique identifier when originally requesting the content creation from Documaker.

In the On Demand scenarios listed above, the mobile output is provided back to the web portal via the calling web service. While this is a convenient method for providing access to the content, it is possible to generate the content on demand, have Documaker store the content in a content repository and provide the locating details back to the calling application. None of the methodologies presented dictate where the mobile content ultimately resides. Where you want the content to reside should guide how the mobile content is accessed. Additionally, the two concepts do not need to be related. Your company may choose to provide mobile output back to the web portal within the Documaker Web Service response but to also store the output in WebCenter Content repository for subsequent access and retention considerations. The decisions on where and for how long to retain the output in this format depend on your company's requirements to retain and reuse the output.

Mobile supporting files

Mobile output produced by Documaker may be self-contained but it's likely that your implementation will have external resources needed for Mobile output display. Items such as bitmaps and JavaScripts can in that case be versioned and stored separately from the Documaker Mobile content. Therefore your infrastructure will need to include a web server or provide sufficient access to this static content. The Documaker Mobile output generated must be able to properly reference to the static content in the selected location.