OSSincorp - Sharing Knowledge and Information on SAP

SAPscript and Smart Form Archiving Technologies

Goto Notes

Preamble:

This article addresses the archiving of SAP based Business Documents that up to and including the Enterprise version 4.7 has been significantly missed in the market place. This lack of archiving implementations has been a factor of technologies and cost.

Three archiving technologies are presented to the reader. The objective is to water down a topic that typically is wrapped in a mystery of a black box of terms. The goal is to elaborate on the archive architectures of three archive implementation strategies and take the mystery out of the process of archiving SAP Business Documents.

Archiving Technology solutions are evolving and with this comes cost effective and XML based powerful solutions. This article introduces two such new products, WEB-Spooler™ and eDocx™.

The objective of the article is to give the reader a firm understanding of the conceptual processes around the mechanism of SAP's archive solution ArchiveLink along with the delivery mechanisms to the third party products like, iXos®, Dazel®, StreamServe®, JetForms® & WEB-Spooler™/eDocx™.

The content identifies the discerning differences with these technologies and will leave the reader in a better position to make more informed decisions on what technology to choose as an archiving solution to SAP's Business Documents.

Top

Discussed will be:

	Note 1:	Reasons for Archiving
	Note 2:	SAP Business Documents
	Note 3:	1980's, 1990's, 2000+, Where is Your Site
	Note 4:	Over-viewing Three Archive Technologies
	Note 5:	Contrasting the Technologies
	Note 6:	Archive-Link Explained as a Process
	Note 7:	ArchiveLink and the Content Server
	Note 8:	The Print Spool as the source of all Business Documents
	Note 9:	SAPscript and Smart Forms are in an OTF file format (Output Text Format)
	Note 10:	WEB-Spooler™ / eDocx™ Driving a New Wave of R3 Archiving Technology
	Note 11:	outlining the WEB-Spooler™ / eDocx™ Server Technology
	Note 12:	SAPscript/Smart Form Documents Transformed to eDocx™ XML DOMs
	Note 13:	What Role will PDF Format Play in the Long Term
	Note 14:	SAP's Technology, Evolution and Shortcomings
	Note 15:	SAP's XML Technology XSF - Contrasting XSF and RDI Output Formats
	Note 16:	eDocx™ Output Process Explained
	Note 17:	Contrasting WEB-Spooler™ / eDOCX™ with Four Current Technologies
	Note 18:	How eDocx™ Will Work with mySAP® Solutions
	Note 19:	Summarizing Document Archiving Solutions

Note 1

reasons for archiving

Top

Bot

Customers of SAP software over a short period of operation soon come to realize there are two components of archiving needs, one resulting from exponential data storage volume growth and the second from business documents like Invoices and Delivery Notes.

Note 2

SAP BUSINESS DOCUMENTS

Top

In contrast to Reports, business documents are transactional in nature. They represent an action to be carried out. Further, they hold a place in a chronological workflow of transactions between people and job role activities.

Reports on the other hand are statistical summarizations in nature and are used to both reveal operational performance as well as become supporting material for strategic planning.

Bot

Typically the cost to create and stabilize an SAP Document Base Infrastructure can be in the millions.
See "What SAP Has Cost You" for a Costing Model referencing a real case site used in this article. This customer spent just under six million dollars to establish their Document handling infrastructure and after a 3.1H to 4.6C version upgrade still have their document infrastructure constrained to pre-internet 3.1H functionality.

The realities are, the creation of a Business Document Infrastructure is expensive. SAP has provided the powerful toolsets and supporting infrastructure, SAPscript and Smart Forms, to address the creation and distribution of issued documents.

Customers continue to hear, “wait till the next version release of SAP and your current operational shortcomings will be addressed”. Well 4.6C was proudly earmarked as the Internet / XML enabler of documents via their new toolset Smart Forms.

While this tool has the design intent to carry out XML documents, 4.6 customers have discovered they could not migrate their core Document Handling Infrastructure from SAPscript to Smart Forms without significant costs and risk. Time and budget constraints forced the hand to do just a technical upgrade that excludes the new technology.

Note 3

1980's, 1990's, 2000+, Where is your Site

Top

Bot

The distribution and handling of documents have involved three waves of technologies where progressively the cost of distribution has decreased with each wave. A dominating cost component with the 1980’s and 1990’s are expensive duplicating copiers and manual labor steps associated with Document flow and Records Management.

From this schematic, two realities warrant discussion. One, the customer handling of the documents as circled in red show their infrastructure is moving to a paperless office, creating pressures on your infrastructure. This paperless, cost cutting end point is most likely your strategic goal as well.

A second, not so evident but very much a significant issue, surrounds a reality that 90 to 95% of all SAP based sites do not archive their issued documents, even though data archiving may be in place. Probably most upper management at these locations do not realize re-issuing the documents will most definitely result in variance. The customer who holds the legally binding document can reference information that is different from the re-issued document. This comes about due to the fact that SAP issued documents are based on current information, not the past.

Note 4

over-viewing three archive technologies

Top

Bot

ADK (Archive Development Kit)	The process of composing data extracts around Business Objects such as Sale Orders with all its related objects like Delivery content and Invoice details is facilitated by SAP’s ADK process. This tool does the packaging of data content.
SAP ArchiveLink	This tool is a storage mechanism tool-set provided by SAP. It becomes the conduit for moving content out of the SAP as well as retrieving archived SAP content from external content servers. This tool handles the dynamics of transfer out to and Retrieval from external content servers back to SAP.
Contrasting ADK and ArchiveLink	The archival of data has to involve both the Archive Development Kit as well as ArchiveLink, where as the archival of SAPscript and Smart Form documents only involves SAP ArchiveLink.
DART (Data Retention Tool)	This tool is a layer of reporting on archived content. It provides access to the externally archived content via ArchiveLink.

Note 5

contrasting the Technologies

Top

Bot

The current SAP architecture for Image Technology as well as SAP Print Driver Technology comes down to working with the output in one of two Output Handling processes.

·	An OTF conversion to a non-ASCII final output device format ready for that mediums output

·	An ASCII SAP file format to an ASCII final output format to be passed to an external application for formatting

OTF Process Overview of Image and Printer Driver Technology

RDI Process Overview of Printer Driver Technology

Process Overview of WEB Enabling Technology

The architecture for WEB-Spooler combined with eDocx is seen as a non-intrusive bolt on that transforms all SAPscript and Smart Forms output to a three node XML DOM. This process is established when the original document is being created.

Note 6

ARCHIVELINK - EXPLAINED AS A PROCESS

In order to evaluate the the technologies built around archiving SAP documents, a conceptual feel for the ArchiveLink process can only help. The process is explained in first seven steps seen below.

Top

Bot

1	Invoice Document is requested and starts the Output Process
2	Execute a Customer Business Process Function that sets the archive settings
3	SAPscript Print Program is executed
4	Archive settings are passed to the OPEN_FORM function
5	A SAPscript document is created in memory in a file format OTF
6	As part of the CLOSE_FORM call, the SAPscript composer will manage the call to the archive process
7	Archive Process will be called and trigger Archive Link
8	SAPscript Composer passes memory version of the document to the Output Spool

A new business document created under SAPscript starts with the “open_form”. When the final document has all the content, its completion is established with the “close_form” function call. Contained within this final function are the archival calls should they be configured on.

The archival process basically builds an HTTP string for the content server, populates cross-reference tables with key information for later calls to the content server to get the URL string for document retrieval along with Object classification attributes to identify the document.

A point needs to be raised, the output handling of archivelink slows the process down significantly. This happens by way of explaining the four sequences of steps that are looped for each document being generated.

Note 7

ARCHIVELINK and the content server

Top

Bot

1	close_form call – finishes the creation of the new document

2	call the archivelink process. This builds up an HTTP string, calls the content server and waits for the acknowledgment

3	When the content server finishes with the call then return a message back to SAP and update archivelink tables.

4	finally append the document to the spool file and repeat the process.

Note 8

the PRINT spool As the source of all saP documents

Top

Bot

1	On any given day, multiple Business Documents are issued and end up in the Spool

2	The Spool retains all documents issued that are set to stay on the spool after printing up to a retention period of 8 days.

3	An Individual Spool file may contain multiple Documents. In this case this file could contain the invoices against 245 Customers

4	An Individual Spool file may contain one and only one Document

The best archiving tool will be the one that takes the best advantage of the spool content.

Note 9

sapscript and smart forms
are in an otf file format
(output text format)

Top

Bot

SAP has two internal file formats, LIST1S for reports and OTF for SAPscript
and Smart Forms.

The content seen on the left is an extract of the Purchase Order and is an example of the OTF format.

OTF has been retained by SAP from versions 2.x right up to
and including 4.7

WEB-Spooler has worked out the mechanics of unraveling this format.

Note 10

WEB-Spooler™ / eDocx™ DRIVING A NEW WAVE
OF ARCHIVING R3 TECHNOLOGY

Top

Bot

eDocx™ - ERP-Link (www.erp-link.com)

eDocx™ - for SAP R/3

A	Through a configuration table, WEB-Spooler issues the same Invoice.
1	Standard SAP Output handling executes and the creation of the new document finishes with the close_form call
4	Steps 2,3 from ArchiveLink process are dropped. Step 4,append the document to the spool file and repeat the process is carried out.
B	When the output handling finishes it passes control back to WEB-Spooler.
C	Get the spool file contents.
D	WEB-Spooler extracts the classification data content from the document, converts the SAPscript format to PDF by using existing SAP Functionality, allowing the building of an index cross reference table and the ability to transfer documents to a content repository, for later retrieval of Internet Browsers.
E	WEB-Spooler technology 1 has been rolled into eDocx™, a product jointly developed with ERP-Link and eDMS Document Management Solutions Inc. eDocx is a server based driver in which SAPscript and Smart Forms are passed to it from the SAP application server via WEB-Spooler. eDocx then converts the native SAP document format OTF (Output Text Format) to an XML DOM format.

Every day up to thousands of business documents are created. This ranges from a single issued document as one spool file to a larger spool file containing 2,000 Invoices Letters for example.

WEB-Spooler can integrate into an Archive-Link solution or provide a solution outside of ArchiveLink.

WEB-Spooler provides a simple and straightforward solution that eliminates the overhead of the wait time seen with the HTTP call with each document creation. This is accomplished with WEB-Spooler’s unique design of using existing SAP functionality.

Note 11

outlining the WEB-SPOOLER™ / eDOCX™ SERVER TECHNOLOGY

Top

Bot

Note 12

sapSCRIPT / smart form DOCUMENTS
transformed to eDocx™ XML DOMs

Top

Bot

This XML DOM has three nodes made up of;

·	The actual OTF document content with format and page coordinate attributes allowing XLST transformation to alternative formats like HTML.

·	Holds the PDF equivalent of the document issued under SAP.

·	Actual data content allowing archive classification and/or Smart Documents. An example of a Smart Document will be made available via Microsoft’s Smart Document product InfoBuilder™

These three nodes go beyond supporting the business requirements of archiving or document distribution with new functionality that can be introduced with the Actual Content data node. This now allows establishing the classification fields for later extraction with one very big advantage. ArchiveLink maintains the classification data separate from the actual document being stored. The eDocx XML DOM bundles this information with the archived document which powerfully facilitates archiving SAP Business Documents with new technologies beyond the existing ArchiveLink technologies.

Having data bundled with the DOM also allows integration into new applications that will spawn with new technologies like Microsoft's InfoBuilder™.

Note 13

What role will PDF format play in the long term

Top

Bot

The current direction of Business Documents is unfolding into the domain of a paradigm shift of paper based manual processes and slow distributions into Internet enabled distribution of XML based documents that are received, regenerated into multiple display formats like PDF or HTML and fed into receiving end applications. The ability to be interfaced into receiving applications becomes the basis of Smart Documents.

PDF documents are not the basis of Smart Documents as they are a format for display. Their content is constrained for a visual target medium. On the other hand, XML based documents accommodate both a visual medium as well as an electronic interface to applications.

As a point in the evolving history of document handling, PDF formatted documents could parallel the microfiche story of the 1980’s. Then, the envelope of technology was to route output to microfiche to allow high volume storage and ease of access. Just as microfiche gave way to CD-ROM technology and digital indexing; PDF documents will share the market if not give way to XML based Smart Documents with the progression of this new wave of Smart Document technology.

Note 14

SAP's technology, evolution and shortcomings

Top

Bot

History can speak for itself. Since the inception of SAPscript from the late 1980's there has not been a shift away from OTF based documents. This speaks highly for SAP's vision of a built in Business Document infrastructure. One competitor, PeopleSoft® does not even have a built in Document Handling Infrastructure making it dependent on third party vendors like JetForms®. The reality is OTF (Output Text Format) has been a powerful solution.

SAP has continued the OTF architecture with Smart Forms. Upgrades into 4.6C or the Enterprise version of 4.7 involve technical upgrades with the outcome of maintaining SAPscript as SAPscript. With 35,000 SAP Customer sites world-wide, replacing a very successful OTF infrastructure will take 10 to 20 years. Migration of ingrained SAPscript processes can not migrate to Smart Forms without great effort, high costs and business risks. Check the article "Comparing Smart Forms to SAPscript" for more details on this front.

Note 15

SAP's XML technology XSF
Contrasting XSF and RDI Output Formats

Top

Bot

SAP BC published Interface information can be seen at SAP Partners -- Integration & Certification

XSF stands for XML for Smart Forms. It is important to contrast XSF with SAP's earlier output interface RDI (Raw data Interface)

Details on this technology can be seen at BC-XSF

Details on the Raw Data Interface technology can be seen at BC-RDI.

Contrasting XSF and RDI: Three points of similarity are,

·	The external system alone is responsible for the layout and administration of the document data

·	Using an external system you loose tight integration with the R/3 System

·	Extra expense is incurred each time you adapt a standard form, since the system has to adapt both an internal and external form.

It becomes important to realize that utilizing XSF will still require the expense of designing and maintaining a separate transformation of data to a visual medium for human access. The elements of the cost here can parallel the RDI interface handling like JetForms. Aside from the cost of another application layer, sites that used JetForms® often had to accommodate code changes in the Print program to accommodate the peculiarities of the JetForms processing. This led to more complicated maintenance issues and costs.

Note 16

eDocx™ OUTPUT PROCESS EXPLAINED

Top

Bot

With OTF, RDI and XSF introduced, eDocx can now be explained as an Output Process. The schematic below shows how eDocx™ fits in the SAP Output Process. The elements of the design has two components:

A front end Configurable component that works with the existing Forms configuration that SAP uses for all SAPscript and Smartforms. This component calls the RFC that connects to eDocx application on the Server.
A RFC that communicates with the TEMSE holder of the OTF output and further gets the data dictionary details on the data content within the SAPscript and Smartform. This is passed back to the server application which conversts the output to a 3 node XML DOM.

This diagram nicely shows the non-intrusiveness of eDocx™ as it can be seen to have its technology configured in without affecting existing Production Print Programs and Forms.

Click for a Larger Scale of this Diagram

Note 17

contrasting WEB-Spooler™ / eDocx™ with
four current technologies

A high level view of the technologies will show the distinguishing factors to involve the delivery mechanism of a Print Driver component versus an RFC (Remote Function call) server component.

Top

Bot

IXOS® IXOS Site	The document format for image technology is PDF, TIFF and BMP. SAP directs IXOS® output via their "C" call Print Driver and have incorporated IXOS® into their "C" library infrastructure. Integrates directly with ArchiveLink.
STREAMSERVE® StreamServe Site	Streamserve® accommodates two output file formats. One is the final format that SAP produces for the target output device, for example Post-Script. The second is a proprietary format that is specific to a Streamserve solution. This format is ASCII based and as it is in an ASCII format, an additional visual building tool is required within Streamserve to rebuild a FORM layout. Streamserve can generate PDF formatted files .
DAZEL® DAZEL Site	DAZEL® accommodates the final format of all SAP targeted printer devices. DAZEL has the functionality to recreate a PDF version of the output if required and further manage the successful distribution of the output. WEB publishing the output is possible. Integrates directly with ArchiveLink.
JETFORMS® JetForms Site (now owned by Adobe)	JetForms® requires modifying the base SAPscript FORMS to implement a proprietary format that is specific to a JetForms solution. This format is ASCII based and as it is in an ASCII format, an additional visual building tool is required within JetForms to rebuild a FORM layout. Integrates with ArchiveLink directly.
WEB-SPOOLER™/eDOCX™ WEB-Spooler	WEB-Spooler™/eDocx™ takes all SAPscript and Smart Form output for all Printer and Fax Devices, converts this output to a 3 node XML DOM containing the original OTF document, a PDF version as well as tagged content data. The WEB-Spooler/eDocx solution is an ABAP bolt on that works with the existing infrastructure. The Print Programs and Forms (layout sets) remained untouched making for an un-obtrusive bolt-on. Contains a powerful script engine for routing documents to third party applications including email exchange. WEB publishing is possible, integrates with third party applications like Microsoft Share Portal Solutions and their newly announced XML application InfoBuilder™. Integrates directly with ArchiveLink.

Note 18

how eDocx™ will work with mySAP® solutions

Top

A good technical reference on mySAP technology can be found on SAP's web site mySAP Technology White Paper (pdf) Two significant architecture components of the WEB-Spooler / eDocx solution make a mySAP solution possible.

·	As WEB-Spooler is written in standard ABAP it can thereby be migrated to a Java ABAP solution with a WEB-Application Server or remain as an ABAP process under an R3 application server solution.

Bot

·	The eDocx script engine can provide a script to convert the file format to an iView format.

The sequence of output for an eDocx document within a mySAP architecture is:

1	Issuing a document out within a mySAP application will call the front end WEB-Spooler application as directed by the output configuration.

2	WEB-Spooler does an RFC call to the eDocx server and the eDocx server gets the spool content and converts the OTF file to a 3 node eDocx XML DOM

3	The eDocx script runs and converts the eDocx XML to an iView XML equivalent

4	The existing mySAP architecture of viewing iView files now has access to the document issued.

Note 19

SUMMARIZING DOCUMENT ARCHIVING solutions

Top

Before a short summarization of the article just read, the points discussed were:

·	Legal implications of not archiving Business documents

·	A way to establish a cost to date for your SAPscript / Smart Form infrastructure

·	Over-viewing the three archive technologies - image, print driver extensions, web-spooled

·	SAP output file formats and delivery mechanisms - Discussed were OTF to ... and RDI to ...

·	Explaining ArchiveLink from a schematic process - a picture is worth a 1000 words

·	Over-viewing WEB-Spooler™/eDocx™ - an R3 enabler of web-spooled technology for archiving

·	What role will PDF and XML based documents play in the future of archiving Documents

·	The evolution of present day SAP document handling technology - it's short comings

·	Contrasting SAP's new XML format XSF (XML for Smart Forms) with RDI (Raw Data Interace)

·	eDocx™ Output Process Explained

·	Contrasting WEB-Spooler™/eDocx™ against iXos®, Dazel®, StreamServe®, JetForms®

·	How WEB-Spooler™/eDocx™ will work with mySAP® architectures

It is realized that business decisions around choice of technical architectures has to be reviewed from a matrix of features and functionality against current technical architectures and business strategies. This article will now give you a means to build 3 matrix scenarios involving now 3 technology flavors of archiving SAP business documents.

To avoid jumping on a band wagon solution for any one of the three technologies, take the time to look deeper into the underlying processes and features of that technology. Keep in mind how many technologies are involved in anyone of the three solutions. Further what it costs to put and maintain a document into a viewable format. Also, keep an eye on how flexible and accommodating the underlying technologies are in working with existing SAP document handling infrastructures.

A good business document archive solution is the one that is the least intrusive and delivers the best functional punch for your budget.

If this technical article delivers on its intent, you now have a way to measure the best decision for archiving SAP® Business Documents.

A SAPscript P/O Spooled to eDocx™ to HTML

Copyright:	Osberg Software Services Inc.
Web:	www.ossincorp.com
eMail:	k_osberg@yahoo.com