Thursday Mar 26, 2015

Documaker Integration : A Primer

Integration of a document automation system with external systems is a critical phase in any Documaker implementation. Whether Documaker is being deployed in a “green field” scenario or into a mature enterprise the fact remains that integration must occur on one or more levels. My goal in this blog post is to explore some concepts and methods required to define and establish integration available in a typical implementation of Oracle Documaker Enterprise Edition, with the hope this may help readers think about possible solutions for their own use.

Establish the Foundation

As I mentioned, Documaker has two possible implementation targets: the green field and the established enterprise. Each target presents both unique and common challenges that must be overcome during the project. In a green field implementation, the software packages being implementation are typically new from top to bottom. This type of target is typically encountered when a brand new company, business unit, or product line is being built from the ground up with new systems, procedures, and software. Implementing within the established enterprise refers to the process of upgrading or replacing an existing software package, or implementing new software within an existing infrastructure. This implementation is most often used with established companies, units, or product lines and serves to enhance functional offerings of the enterprise to serve the needs of the business. In both cases where Documaker is concerned there will be integrations – either to new or existing software, processes, and procedures, which form the basic foundation of the enterprise. In order to perform the subsequent steps, we must know capabilities of the foundation. Therefore, the final activity in this step is to establish a functional catalog of capabilities offered by each component of the system. The table below illustrates one such method of capabilities cataloging.

Table 1, Capabilities Catalog

ID

System

I/O

Type

Method

Format

Notes

CAP-1

Policy Administration System

Output

Flat-file

File system delivery

Fixed-record format

Schema dictated by product. Can add new record types and data

CAP-2

Billing System

Output

XML

Web Service

Fixed Schema

XSL-controlled schema, fixed element names. Cannot add new elements.

CAP-3

Content Management System

Input

SOAP

Web Service

Fixed Schema

Product-controlled schema. New data elements can be added.

This table illustrates how the input and output capabilities of various element in the foundation system and how they may (or may not) be changed to accommodate additional business requirements.

Data Flow Mapping

Having defined the capabilities, we can now further refine business requirements and (hopefully) obtain a match between the requirements and capabilities. When performing a Documaker implementation, part of the business requirements analysis will involve form and data analysis. This analysis defines, among other things, the data needed for document triggering, data mapping, and controlling other aspects of handling document automation. This information constitutes requirements for systems that feed information to Documaker (“upstream” systems). Similarly, there may be a need for Documaker to feed information to systems after processing (“downstream” systems), such as archive repositories, publishing systems, delivery systems, and the like. By now you can probably see that defining the upstream and downstream requirements is directly related to the table of capabilities we developed in Step 1. From here we can further refine our data requirements for each system. The table below represents a simplified view into cataloging the data requirements for each system:

Table 2, Data Requirements

ID

System

Capability Map

Element

Source

Notes

DR-1

Content Management System

CAP-1

Account Number

RECORD ID=100

FIELD=ACCT_NUM

Required for indexing output

DR-2

Mail Processing System

CAP-2

XML

Document barcode (see barcode requirements)

Required for sorting mail pieces to obtain postal discounts.

Once these two steps have been fully executed and mapped out, we’ll have an accurate picture of all upstream and downstream data requirements as well as a map of how those data elements can be captured and passed between systems.

Targeting Documaker

At this point, what we have defined is not specific to Documaker – the steps I’ve outlined above are very generic and could be applied to any software implementation in any enterprise where data interchange and software integration is required. The key is that we are now in a frame of mind where we can start to consider the integration capabilities of Documaker, and how they will map into a possible solution. What better way to do that than to present a capabilities catalog for Documaker Enterprise Edition, as we would do in an actual implementation! The table format I’ve chosen to represent the capabilities catalog is slightly different from Table 1, as I have formatted the table to represent capabilities specific to Documaker.

Table 3, Documaker Input Channels

Model

Transport

Type(s)

Notes

Transactional Input

Hot Folder

Web Service

Direct Queue

Flat-File

Record layout dictated by upstream capability, informed by form requirements and downstream requirements. Only one layout supported per assembly line.

Transactional Input

Hot Folder

Web Service

Direct Queue

XML

Schema dictated by upstream capability, informed by form requirements and downstream requirements. Only one schema supported per assembly line.

Consolidation

ETL-to-Transactional Input

Flat-file

XML

Databases

Other Files

ETL Tool such as Transall, a Documaker component, is used to consolidate multiple input sources into a single transactional input.

Interactive Augmentation

Documaker Interactive

Web Service-to-various

Documents that are processed in Documaker Interactive can be augmented by external data, which is retrieved by Documaker Interactive using a custom web service. This service accepts input from Documaker Interactive (which is transactional or user entered data) and then performs operations to retrieve additional data, format if necessary, and return using a pre-defined schema.

Scripted Augmentation

DAL –ODBC

DAL-File

Database or File-based

DAL-scripting can be used to obtain data from external sources to augment transactional data or for use during processing as needed. This method is usually not recommended as it can present problems when scaling across servers. The preferred model is Consolidation or Interactive Augmentation.

The following table outlines the output capabilities of Documaker.

Table 4, Documaker Output Channels

Model

Transport

Type(s)

Notes

Archiver

s/FTP

Web Center: Content (UCM)

File System

Publication Streams

Metadata Files

This channel is a standard output delivery channel included with Documaker. The Archiver component is used for transmitting documents generated by Documaker to various destinations. Archiver also has the capability to emit accompanying metadata files in arbitrary (user-defined) formats. Metadata includes any information related to the transaction that is carried in the ODEE table structure. Typical uses would be to submit documents to archive systems with indexing data in the metadata file.

Customization

Various

Publication Streams

Metadata

The Archiver component has an open framework for adding new output destinations (transports) in addition to those shown above. A typical use case is to write a custom integration to a system that has integration requirements not satisfied by the default transports, e.g. invoking a web service to transmit publications and metadata.

Distribution

Web Services

Dashboard

Query

Publication Streams

Metadata

Documaker supports multiple methods of self-service integration. While the Archiver and customization hooks provided by Archiver are a push model, the Distribution channel is a pull model – suitable for self-service integration via web services, database queries, or using the Dashboard UI.

Notification

SMS

Metadata

This channel is a standard output delivery channel supported by Documaker which notifies a recipient that a document has been generated.

Publication

Email

Printer

Publication Streams

This is a standard Documaker output delivery channel used for pushing documents directly to attached printers, and for sending documents via email.

Instrumentation

JMX

Statistics

This channel is often overlooked, but can be configured to allow ODEE Factory Workers to output statistical information.

While the preceding tables are not exhaustive of all of the possible integration points with Documaker, they are the most common. Some of these channels aren’t considered traditional integration points, but they are useful when thinking about systems management of an enterprise solution that includes Documaker.

I hope you find this information useful!

Wednesday Oct 29, 2014

Why Projects Fail

I'm going to divert a little from my technical orientation for blogging here and discuss something that's critical to any software implementation: project failure. 

To properly frame the discussion about why projects fail, we first need to define a project. The Project Management Institute (“PMI”) defines a project as “a temporary group activity designed to produce a unique product, service, or result.” (What is Project Management?). This is in contrast to routine activities that use repetitive processes to generate a product or service, such as manufacturing or customer service. PMI further stipulates that a project is temporary because the beginning and end, scope and resources are finite and defined to achieve a singular goal. Timeline, scope, and resources, are the three factors that exert direct influence over the success of project. Each must be in balance with the other two for the project to meet its goals – if the scope becomes too large, the project will exceed available resources (personnel or budget). Similarly, if the timeline becomes compressed, the scope and resources will not be able to deliver on time. With the triangle of time, resources, and scope in mind, we can say that a successful project is one that is delivered within the timeframe, using the identified resources, and meets the agreed-upon scope.

Having defined a project, we can then explore the concept of project management. Again, PMI provides a broad definition: “Project management, then, is the application of knowledge, skills, and techniques to execute projects effectively and efficiently” (What Is Project Management?). The collection of knowledge, skills, and techniques that have been refined over time to produce reliable, repeatable results are called a methodology. A project management methodology is the primary tool used by project managers to ensure the successful delivery of a project. There are many different methodologies such as SCRUM, Agile, Waterfall, and SLDC to name a few (Project Management Methodologies). The project manager uses the methodology to guide the project to completion by controlling the three legs of the project triangle.

With this framework in mind, we can explore the failure points of the triangle. The scope leg of the triangle involves the definition, acceptance, and management of the requirements of a project. A project that has ill-defined requirements, which do not meet the needs of the users, or users who are unable to achieve consensus on requirements, or pressure to execute before requirements are defined is set on a path to failure (Why Projects Fail). The presence of ill-defined requirements can also be a symptom of two broader problems that can lead to project failure: management buy-in and project communication. Project sponsors, executives, and leaders must be in agreement on the high-level deliverables of a project. When these stakeholders are not in alignment, the project scope will be unclear; the project will be in jeopardy. Similarly, the users must also be aware of the goals of the project, otherwise the requirements they devise may be at odds with parameters of the project. These two factors can be managed with clear, concise communication at all points.

With the scope leg of the triangle properly defined, the time and resource legs can then be constructed. It is possible that the project timeline may be set before the scope has been identified, in which case the project will require additional resources to complete on time. When scope and resources are not properly aligned the project may experience cost overruns or late delivery, both of which constitute failure. One method to avoid misalignment is to use proof-of-concept or pilot programs. These programs can help determine viability of an approach to meeting scope requirements within time and resource constraints, which will improve the chances of success.

When the three legs of the project management triangle have been properly defined, agreed-upon, communicated, and have resources allocated, the remaining step is to execute the project using the methods prescribed by the chosen methodology. Herein also lie additional failure points for the project, one of which is reactive management. If a project starts to exceed the constraints of time, scope, or resources, the application of risk management should be used to return the project to the boundaries of control. Proactive risk management includes proper identification, analysis, and mitigation of project risks before they occur. Failure to perform proactive risk management will cause problems to be addressed in a reactive manner, which will result in schedule slippage, and budget/resource overuse (Why Projects Fail).

In conclusion, we have identified multiple factors that can negatively affect the outcome of a project:

  • Ill-defined requirements;
  • Management buy-in;
  • Communication;
  • Alignment of scope and resources; and
  • Ineffective risk management

 

I have also presented some common ways that these pitfalls can be avoided to help guide a project to success. I hope you find this information useful and can avoid project failures in your own endeavors.

References:

  • What is Project Management? (n.d.). Retrieved October 15, 2014, from http://www.pmi.org/About-Us/About-Us-What-is-Project-Management.aspx
  • Project Management Methodologies. (n.d.). Retrieved October 15, 2014, from http://www.tutorialspoint.com/management_concepts/project_management_methodologies.htm
  • Why Projects Fail: Avoiding the Classic Pitfalls. (2011, October). Retrieved October 15, 2014, from http://www.oracle.com/us/solutions/018860.pdf

 

Tuesday Jul 08, 2014

How to Publish with EWPS - Quick Guide

Getting Started with Documaker and Web Services 

Today I'll be addressing a common question - how do I get started publishing with web services and Documaker? The aim of this guide is to give you a quick rundown on how you can be up and running with publishing via web services and Documaker within a few hours, or even minutes! Before we get started, I think it's pertinent to discuss web services. 

[Read More]

Thursday Jun 12, 2014

ODEE Green Field (Windows) Part 5 - Deployment and Validation

Part 5 of a multi-part blog series on creating an ODEE green field - a sandbox environment with all necessary software components for a deployment of Oracle Documaker Enterprise Edition. This includes Oracle database, SOA Suite, WebLogic application server, and Documaker. This sandbox series covers Windows versions of the software. In this installment, Documaker is deployed and tested to complete the installation.[Read More]

ODEE Green Field (Windows) Part 4 - Documaker

Part 4 of a multi-part blog series on creating an ODEE green field - a sandbox environment with all necessary software components for a deployment of Oracle Documaker Enterprise Edition. This includes Oracle database, SOA Suite, WebLogic application server, and Documaker. This sandbox series covers Windows versions of the software. In this installment, Documaker is installed.[Read More]

Wednesday Jun 11, 2014

ODEE Green Field (Windows) Part 3 - SOA Suite

Part 3 of a multi-part blog series on creating an ODEE green field - a sandbox environment with all necessary software components for a deployment of Oracle Documaker Enterprise Edition. This includes Oracle database, SOA Suite, WebLogic application server, and Documaker. This sandbox series covers Windows versions of the software. In this installment, SOA Suite is installed.[Read More]

ODEE Green Field (Windows) Part 2 - WebLogic

Part 2 of a multi-part blog series on creating an ODEE green field - a sandbox environment with all necessary software components for a deployment of Oracle Documaker Enterprise Edition. This includes Oracle database, SOA Suite, WebLogic application server, and Documaker. This sandbox series covers Windows versions of the software. In this installment, WebLogic is installed.[Read More]

Monday May 19, 2014

ODEE Green Field (Windows) Part 1 - Intro & Database

A multi-part blog series on creating an ODEE green field - a sandbox environment with all necessary software components for a deployment of Oracle Documaker Enterprise Edition. This includes Oracle database, SOA Suite, WebLogic application server, and Documaker. This sandbox series covers Windows versions of the software. In this installment, the Oracle database is installed.[Read More]

Friday Mar 12, 2010

Demystifying Docupresentment

In this edition of Inside Document Automation, Andy takes a look at Docupresentment, a powerful queue-based tool for integrating on-demand and interactive applications with Documaker. Learn about downloading, installing, and basic configuration in this post![Read More]

Thursday Mar 11, 2010

By Way of Introduction...

With this inaugural post to Inside Document Automation, I'm going to introduce myself, and what my aim is with this blog.  If you didn't figure it out already by perusing my profile, my name is Andy and I've been with Oracle (nee Skywire Software nee Docucorp nee Formmaker) since the formative years of 1998.  Strangely, it doesn't seem that long ago, but it's certainly a lifetime in the age of technology.  I recall running a BBS from my parent's basement on a 1200 baud modem, and the trepidation that accompanies the sweaty-palmed excitement of upgrading to the power and speed of 2400 baud!  I'll admit that perhaps I'm inflating the experience a bit, but I was kid!  This is the stuff of War Games and King's Quest I and the demise of TI-99 4/A.  Exciting times.  So fast-forward a bit and I'm 12 years into a career in the world of document automation and publishing working for, in my humble opinion, the best software company on the planet. 

With Inside Document Automation I hope to peek under the covers, go behind closed doors, lift up the hood and bang on the fenders of the tech space within Oracle Documaker.  I may delve off course a bit, and you'll likely get a dose of humor (at least in my mind) but I hope you'll glean at least a tidbit of usefulness with each post as I shed a little light in the underpinnings of our software.  Feel free to comment as I'm a fairly conversant guy and happy to talk -- it's stopping the talking that's the hard part... So read on!

About

A technically-focused, in-depth look at Oracle Documaker including the Enterprise and Standard editions and the software components thereof (Docupresentment, EWPS, DWS, and more).

Search

Archives
« May 2015
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today