Using the Adobe XML Architecture to Extend Processes with Intelligent Forms

Transcription

1 Using the Adobe XML Architecture to Extend Processes with Intelligent Forms by Kumar Vora, Vice President of Product Management Strategy, Adobe Systems Incorporated Summary: This article describes how you can use Adobe s technology for electronic forms, based on the Portable Document Format (PDF) and the extensible Markup Language (XML), to meet the electronic form requirements of enterprise environments. The Adobe XML architecture is part of the Adobe Intelligent Document Platform, which enables enterprises to communicate more effectively, automate document-based processes, access systems offline, share information securely, and exchange data and information with people and systems. Optimized for IBM WebSphere, the Adobe Intelligent Document Platform creates Intelligent Documents that can be used throughout the IBM middleware application stack to extend business processes, provide better interaction between systems, and improve communications with partners and customers. Data capture and document generation are often critical elements of enterprise applications and present difficult development challenges. It is difficult for developers to ensure that the captured data is properly bound to the desired XML schema. Using a custom JSP approach to implement end-to-end XML schema binding in data capture or document generation processes makes it difficult to keep solution components up-to-date and increases maintenance costs as the solution and schema change. Generating documents that are presented consistently independent of the delivery channel be it Web, , fax, and/or paper can be laborious development tasks and create maintenance headaches. By blending the data integration power of XML with the presentation capabilities of PDF, Adobe s Intelligent Document Platform extends the WebSphere environment to streamline the development and maintenance of data capture and document generation processes. Developers can do end-to-end XML schema binding for data capture and document generation processes without increasing maintenance costs with custom JSP programming. The Adobe Intelligent Document Platform delivers a suite of Document Services process management (including data capture and integration), document generation (including document output), document security, and collaboration that can be delivered to virtually any desktop either via Adobe Reader and/or a Web browser, as well as via printed documents. Using the Adobe platform, WebSphere developers can take actions or initiate processes based on data collected and submitted from electronic PDF/XML forms. Once a form is received, WebSphere developers can use Java code to route the data contained in the form to the appropriate business process. In addition,

2 applications developed with WebSphere Studio Application Developer can generate and distribute Adobe PDF documents as a persistent record of an interaction between the user and the system. IBM WebSphere developers can use the Java tools in WebSphere Studio Application Developer to create, deploy and integrate forms-based processes into any enterprise application running on the WebSphere platform. Adobe Intelligent Documents easily integrate with WebSphere applications using XML, HTTP, SOAP (Simple Object Access Protocol) and Web Services Definition Language (WSDL). Extending processes with forms and documents As organizations modernize with Web services and electronic processes to offer more convenient services and gain efficiencies, they need to give people outside the firewall access to these services and processes online. To make processes more efficient, data collected from people must be automatically updated to core business systems. Processes also need to provide information back to people in a timely fashion. It is not feasible to use specialized client applications to move data back and forth and present an interface to people for data collection outside the firewall. Client licensing requirements might limit the client s distribution, but even without limits the logistics of distributing, installing, and managing a specialized client outside the firewall are costly and time-consuming. Rather than distributing a client application to thousands of people who then have to learn how to use it, you can use electronic forms that can be opened with the free, ubiquitous Adobe Reader software over 500 million copies have already been distributed. With the combination of the Adobe Intelligent Document Platform and the IBM WebSphere enterprise application integration environment, developers can create electronic form interfaces that directly integrate into J2EE enterprise applications and business processes. The result is improved data accuracy and savings in time and money. In fact, with the Adobe Intelligent Document Platform, companies can eliminate parallel paper-based processes, because data capture and entry only occurs once. When the form and/or its embedded data are received, WebSphere developers simply use Java code to route the data to the appropriate business process. Electronic forms are an ideal general interface because paper forms already drive most processes. The challenges in using electronic forms for data collection and service interaction are to provide forms that visually match their paper counterparts, integrate the data in forms with the data formats supported by core systems, and generate datapopulated forms and documents from electronic processes. The Adobe XML architecture meets these challenges by leveraging Adobe Reader and a sophisticated processing model that separates data, visual layout, and business logic.

3 People can work with familiar PDF forms, while applications can interact with XML data formatted properly in the schema used by the organization. The forms can be used offline and routed by for review. Unlike Web pages, the forms can be secured and saved as documents of record. Using the Adobe XML architecture organizations can effectively bridge paper and electronic forms and, through the use of barcodes, efficiently use paper documents in electronic workflows. The Adobe XML architecture The Adobe architecture assigns processing responsibility for each type of information to a different module, and provides a programmatic interface for each module. This enables a clean separation of responsibility among the tasks of layout design, data integration, and application processing. Form layout designers can use visual tools; system integrators can provide the appropriate XML schemas; and application developers can use off-theshelf XML tools to extract the information they need. As a result, enterprises can quickly and cost-effectively extend their core processes to people outside the firewall and make them more efficient. Intelligent Documents are dynamic documents that contain visually rich interactive content, intelligent logic and XML data (see Figure 1). By adding interactive form fields, you can extend the functionality of PDF documents and enable data capture and presentation, calculations, and validations (using ECMAScript or FormCalc). You can integrate documents into existing workflows using JDBC/ODBC databases; WSDL Web services bindings; and XML schema. You can create and store Intelligent Documents in either the PDF or the XML Data Package (XDP) file format. Documents created as XDP files can be rendered as either an HTML form for access online by a standard Web browser, or as a PDF file that can be opened in Adobe Reader and completed offline, then submitted online.

4 Figure 1. Adobe Intelligent Documents combine the powerful data and business logic capabilities of XML with the rich presentation and document control capabilities of PDF to make it easier for developers to deploy electronic forms as interfaces for capturing data for core systems and to generate data-populated documents from processes. The Adobe XML architecture provides a single, reusable framework that cleanly addresses the issues of fidelity to visual layout, flexibility of data integration, intelligent interaction, multiple-channel delivery, and offline work. It simplifies integration with the enterprise software infrastructure and makes development smooth and efficient. It maximizes the use of visual designers and Web developers and minimizes the use of integration developers and application developers. Complicated scripts from a Web development task can be cleanly encapsulated within the form definition rather than mixed in with layout design. Applications can interact with the form through published APIs for file formats, making the development process easier. Meeting enterprise requirements Most enterprises use a software infrastructure that includes a combination of Web interfaces, custom applications, packaged applications, and back-end databases, running on a variety of operating systems. These pieces generally have different upgrade cycles and application development paradigms. Enterprises typically have already made significant investments in methods of integrating these disparate components. In many cases, industry-standard or internally developed XML schemas shape the format of integration.

5 Arbitrary XML formats To support an enterprise s chosen XML schemas and minimize the work that integration developers would have to do to process the form s XML data, the Adobe XML architecture supports arbitrary XML formats. A designer shouldn t have to redesign the same form layout to accommodate slightly different XML formats. The Adobe XML architecture s data abstraction layer makes is easy to support arbitrary XML schemas while keeping form design easy. The architecture binds data elements from the abstraction layer to the form fields specified in the layout template, and supports bidirectional propagation of changes in one location to the other. Integration with Web services and databases Many enterprises want to integrate online interactions with Web services and back-end databases that comprise core business systems. The Adobe XML architecture supports standard Web services protocols such as SOAP and HTTP, and database connections such as ADO, and JDBC, so that forms can be directly connected to Web services, databases, and core systems. Online and offline interaction It is important for many organizations to allow people to download a batch of forms at once and fill them out offline, at their convenience. Many business processes require different forms at different stages of the process. For example, when applying for a car loan, applicants fill out one form to request approval, and another form once they purchase a car, providing details about the vehicle. Yet another form a promissory note is required to codify the agreed-upon terms of the loan. It is far more convenient for applicants to download the forms and fill them out offline, rather than online using a Web page, as they gather the information they need to complete the process. The Adobe XML architecture supports both online and offline interaction. An Intelligent Document can be deployed as either a downloadable PDF file that can be filled in offline with Adobe Reader, or an HTML page readable in any browser. PDF forms can contain business logic that helps people complete the form possibly even instructions on how to connect to Web services or back-end databases to retrieve up-to-date information. Conformity, visual presentation, and high-fidelity printing Electronic forms and documents should look like their paper counterparts. People can be more easily guided into electronic processes with forms that look like paper and can still be used as printed forms. Global enterprises need to support international standards for paper sizes and text layout. Government regulations may dictate the precise look of forms and documents. Adobe PDF documents and forms look exactly like their original paper counterparts, locking in all the original fonts, graphical elements, and layout formatting an enormous advantage when government or financial forms must conform to specific formats. The Adobe PDF architecture provides an internal page layout model that can render arbitrary data within the specified pagination constraints, maintaining the visual presentation and integrity of the original pages. The Adobe solution can also generate final electronic or

6 printed documents, such as loan promissory notes or contracts, in Adobe PDF automatically, merging in data from core systems to complete the document. Robust security The ability to complete forms offline raises security issues that are addressed by the Adobe PDF document security features. Adobe PDF files offer strong authentication and support for digital signatures, providing control over form and document security even after they have been distributed outside of the organization. Intelligent PDF forms can also improve data integrity by authenticating and authorizing data as people complete the forms. In addition, you can lock the XML data in the PDF file to create documents of record and to comply with standards for electronic document archiving (as recently mandated by the U.S. National Archives and Records Administration). How the Adobe XML architecture works Organizations need more flexibility with XML formats when designing forms. For example, a government agency s core system might store the information for a proposal, including company details, financial details, and technical details, in the same XML format. However, the agency needs to present this information on different forms without having to break apart the official XML schema to accommodate special definitions for these forms. Instead, each type of form should be able to access the part of the official schema that is relevant to its purpose. On the other hand, if an enterprise uses different systems to handle, for example, credit checks, order fulfillment, and order shipping, a single transaction and form might need to generate different XML messages for these processes. This flexibility is only possible with well-designed data abstraction, binding, and scripting capabilities. To provide this flexibility and meet the enterprise requirements for using electronic forms as interfaces to core applications, the Adobe XML architecture cleanly separates the form template from the form data. The architecture uses an XML container for document components that is interchangeable with PDF. The XML Data Package (XDP) file is simply an XML file that encodes a PDF file in XML, along with the form data and a form template (see Figure 2).

7 Figure 2. Anatomy of an XDP (XML Data Package) file: form data is separate from the form template, and form fields are encoded in PDF. The XML form data is encoded according to an arbitrary XML schema chosen by the form developer during the design phase. The XML form template contains all the form intelligence, including the mapping of XML form data to PDF form fields. The XML form template also contains the business logic that controls the interactive behavior of the document, such as calculations and data validations. The XML configuration information is a global reference for database and SOAP connections to Web services. XDP files can include custom XML information such as digital signatures, schemas for data validation, and content metadata for archives. By including other XML schemas, you can make it easy for other systems to process the XML data in the form. Leveraging the Adobe XML architecture While the Adobe XML architecture is sophisticated, it is not complex to use. PDF and XDP are equivalent and interchangeable representations of the same underlying form. With this flexibility you can choose which one to use depending on the specific requirements of the process. PDF offers advantages with large documents that need to be compressed, and documents that contain images. XDP offers advantages with forms that travel in XML workflows, and with systems that manipulate form data with XML processing components or store forms in an XML repository. The Adobe LiveCycle family of server software converts one representation to the other. Organizations can use this architecture by designing forms with Adobe LiveCycle Designer, and using Adobe LiveCycle Forms to deploy the forms along with off-the-shelf XML processing components to populate and extract form instance data.

8 System integrators (SIs) can manipulate XDP files as part of distributed application processing. For example, an SI specializing in a particular industry can develop generic form templates and then programmatically customize them by altering the XDP files to change default values, change validation constraints, customize calculation formulas, suppress certain subforms, or modify security permissions for different user roles. Independent software vendors (ISVs) can use this architecture to embed electronic forms capabilities into their products. Packaged application vendors can add the ability to generate forms and use the programmatic interfaces to the Adobe XML architecture to customize one of Adobe s LiveCycle server products or build their own modules. Adobe used these programmatic interfaces to build Adobe s form-related products; they serve as both a proof point for this level of customization and a technical resource for ISVs. Programming the Adobe XML architecture When an application accesses an XDP or PDF document, it loads the persistent information into a set of runtime modules. The Adobe XML architecture offers programmatic interfaces, called document object models (DOMs), to these modules that can be useful to ISVs (as shown in Figure 3). The Adobe DOMs separate the operations specific to electronic forms, but at the lowest level they manipulate XML data using the standard W3C DOM, so that in-memory representation of data remains synchronized with the XML document representation. Figure 3. Adobe document object models (DOMs) are programmatic interfaces to the separate modules for form data, form template, form intelligence, layout, and XML messages. The Template DOM binds template fields to instance data and manages information related to visual layout, data binding, and interaction rules. The architecture includes default binding rules that map XML data elements to form template fields based on

9 similarities in their respective structural hierarchies as well as element and field names. These default rules simplify the job of template designers, who only have to provide a specific mapping when structure and naming aren t sufficient to calculate the binding. Once binding is complete, changes to the fields or the data are synchronized through cooperation with the Data DOM. The Template DOM also manages scripts in either FormCalc or ECMAScript. FormCalc is an expression language similar to a spreadsheet formula language, used primarily to calculate the values of one field from the values of other fields. FormCalc is intuitive no more complex than doing formulas in a spreadsheet so programming or Web scripting skills are not required. You can use ECMAScripts to create dialog boxes that pop up to offer information or choices, or even to directly access different Adobe DOMs. ECMAScript enables you to turn electronic forms into powerful applications that can even look up a person s security role in an enterprise directory and then suppress access to certain form fields based on this role. The Data DOM manages instance data with an abstraction layer that bridges high-level form data manipulations to low-level W3C DOM operations. The Data DOM can also synchronize form data with information in any ODBC-accessible database or any SOAPaccessible application. The Data DOM dynamically synchronizes the instance data with the form representation managed by the Form DOM. When a form user changes a value in a field, the Data DOM receives the event from the Form DOM and propagates the change. If the data source is XML, the Data DOM makes the change to the in-memory W3C DOM representation or flushes it to a back-end data source. The Form DOM is the runtime representation of the form as a whole, derived from the combination of information from the Template and Data DOMs. While applications and scripts can directly manipulate the Template and Data DOMs, most applications use the Form DOM. For example, as a person changes a form field when filling out an intelligent form, the application (Adobe Reader enabled with Adobe LiveCycle Reader Extensions, or Adobe Acrobat) calls an operation in the Form DOM to change the data. The Form DOM then collaborates with the Template DOM to execute any scripts that depend on the value of that field, and then collaborates with the Data DOM to implement the change in the underlying data representation. The layout model controls the page layout of forms, including page size, headers and footers, and pagination. You can include scripts in the form template that directly manipulate the layout model, or include this logic in specific applications for example, Adobe LiveCycle Forms manipulates the layout model as well as the Form DOM to combine Adobe PDF forms with XML data schemas. e-government example

10 The U.S. government is one of the largest consumers of IT and has evolved a diverse set of back-end systems and integration technologies. It has a broad set of initiatives known as e-government to improve the efficiency of its processes. One of these initiatives is egrants to improve the efficiency of grant making, including those for research and development administered by agencies such as the Defense Advanced Research Projects Agency (DARPA), the National Institutes of Health (NIH), and the National Science Foundation (NSF). The goal is to provide a single online portal for grant constituents that speeds grant applications, makes the review process easier, eliminates redundant information, minimizes administration costs and standardizes the collection of financial report data. Scientists involved in research projects use the egrants portal to download, fill out, and submit a grant proposal form. The data from the form is converted to two different review forms one for the program administrator containing all the information, and another containing only technical information for outside reviewers. The reviewers comment on the proposals, and the program administrator collects the review forms and makes a decision. If the proposal is accepted, enrollment forms are sent back to the scientist for completion, and these forms go back to the administrator for review. Information from these forms is parceled out to the proposal database and the agency s budget system. As the project continues, the administrator receives periodic reports and the government auditors review project finances and file more forms with the finance department. While all this sounds complicated, in fact much of the software infrastructure for automation was already in place with XML formats for the data. After importing existing PDF forms with form fields, or creating new ones by scanning paper forms or designing from scratch and overlaying form fields, agency form designers mapped the existing XML schemas to the form fields. This is as simple as right clicking a form field in Adobe LiveCycle Designer and selecting the correct data definition in a list associated with a specific schema. Once the form is tested it can be deployed in the egrants portal or ed to constituents, who can complete the PDF version of the form offline using Adobe Reader. After filling in the form, constituents can submit the PDF version through the portal or by . Adobe LiveCycle Forms extracts the XML information and routes it to appropriate back-end applications. By using the Adobe XML architecture that separates visual layout from data schema definitions, government agencies can extend processes that work with core systems out to constituents using intelligent forms. They can start from existing form layouts and connect them to core systems, or start from existing XML formats for core systems and create new forms. They can adopt electronic forms as a top-down strategic initiative or as a series of bottom-up tactical projects. No matter what the starting point or adoption approach, the Adobe architecture provides the catalyst necessary to marry user and

11 system representations so that the government agencies can achieve a seamless flow of process data. Conclusion While users and system integrators may agree on individual data elements, they almost never agree on how to organize them. Users adopt a point of view based on job tasks, while system integrators adopt a point of view based on the schemas of their databases. The Adobe XML architecture addresses the different points of view by cleanly separating the form data from the form template, separating the operations with programmable modules, and synchronizing XML form operations with core systems. Adobe shields all this complexity from enterprise designers and developers with document object models (DOMs), which ISVs can use for building electronic forms into applications. Developers can do end-to-end XML schema binding for processes without increasing maintenance costs with custom JSP programming. With the availability of the Adobe Intelligent Document Platform optimized for IBM WebSphere, forms and documents are integrated with the very IT infrastructure and enterprise applications that streamline and automate business processes. Form designers can simply import, modify, and design visual elements using a high-productivity layout tool such as Adobe LiveCycle Designer. Developers can populate, extract, and process the underlying XML data using standard XML software components or Adobe LiveCycle Forms. Together, they give users electronic forms that mirror the popular usage model of paper forms, but with additional intelligence that enables enterprises to extend processes farther and execute faster. This common technology platform allows organizations to achieve improved efficiency, better communications with constituents, and more responsiveness. Additional Information Visit the Adobe page on IBM developerworks for trial software, tutorial, and more, or visit To learn more about the many benefits Adobe PDF can offer, visit for more information, including the published specifications. If you have questions or would like to know more, please ask Adobe ( link).