1 / 49

Welcome To NCAOUG 2007

leia
Download Presentation

Welcome To NCAOUG 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    2. XML Publisher Technology This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

    8. Document Management Requirements This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

    9. Document Management Requirements

    10. No One System Can Do That Costly Time consuming Complex systemsCostly Time consuming Complex systems

    11. Maintenance Cost More Highly-skilled engineers required to maintain the 3rd party software servers Highly-skilled engineers required to maintain the 3rd party software servers

    12. Issues with Classic Reporting Tools This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

    13. Classic Reporting Tools Issue The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    14. Classic Reporting Tools Issue The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    15. Classic Reporting Tools Issue The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    16. Classic Reporting Tools Issues

    17. Classic Reporting Tools Issues The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    18. Why XML Publisher This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

    19. Why XML Publisher?

    20. Integrated Document Management

    21. XML Publisher Concept Separate data / layout / UI translation XML Publisher breaks the three components apart and treats them separately at design time, at runtime the three are brought back together by XML Publisher to generate the final formatted, translated output. There is an immediate gain in that this model is far more flexible i.e. a single data definition can support multiple layouts, multiple translations can be applied at runtime to generate translated output. This leads to a reduction in maintenance costs for all concerned.XML Publisher breaks the three components apart and treats them separately at design time, at runtime the three are brought back together by XML Publisher to generate the final formatted, translated output. There is an immediate gain in that this model is far more flexible i.e. a single data definition can support multiple layouts, multiple translations can be applied at runtime to generate translated output. This leads to a reduction in maintenance costs for all concerned.

    22. XML Publisher Modules This slide summarizes the modules that make up XML Publisher. Data Data engines are registered with the data handler, these can be any engine that generates XML such as Oracle Reports, Service Beans, etc. Template - the layout templates to be used for the final output are stored and managed in the Template Manager. These templates are created using familiar desktop tools such as MS Word, MS Excel or Adobe Acrobat. Translation the translation handler will manage the translation that is required at runtime. Deliver the delivery server will take the output document and deliver to various destinations such as printer, email, fax, etc. This slide summarizes the modules that make up XML Publisher. Data Data engines are registered with the data handler, these can be any engine that generates XML such as Oracle Reports, Service Beans, etc. Template - the layout templates to be used for the final output are stored and managed in the Template Manager. These templates are created using familiar desktop tools such as MS Word, MS Excel or Adobe Acrobat. Translation the translation handler will manage the translation that is required at runtime. Deliver the delivery server will take the output document and deliver to various destinations such as printer, email, fax, etc.

    23. XML Publisher Customization The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    24. CONCEPTS This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

    25. From Data to Delivery The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    26. Extract Once Publish Multiple Times The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files. The classic approach to reporting is to combine all of the elements of a report into a single entity, the data definition, the layout and the translation. This report file is very unwieldy and causes problems due to its inflexibility. If a report is required that has even a minor layout change a new report file must be created to support the new requirement even thou the data definition is exactly the same. If another version of a report is required at runtime in a different language then a new report file must be created to support the new language. This approach leads to more time and expense in maintaining the report files.

    27. XML Publisher Technology Adobe Acrobat MS Word MS Excel XSL Editors Users can design layout templates using familiar desktop applications such as Adobe Acrobat and MS Word, there are now many XSL editors available on the market for the user to take advantage of.Users can design layout templates using familiar desktop applications such as Adobe Acrobat and MS Word, there are now many XSL editors available on the market for the user to take advantage of.

    28. Templates PDF Forms Templates PDF Forms When communicating with 3rd parties there is a requirement that the communication medium should be of an exact format e.g. tax forms. PDF forms can be downloaded from these 3rd parties such as the government and used as report templates. These forms often include fields already embedded in the form layout, in this case the user is able to map the field names to XML data element names. At runtime the PDF form is merged with the XML data to create a filled copy of the original PDF form. Templates PDF Forms When communicating with 3rd parties there is a requirement that the communication medium should be of an exact format e.g. tax forms. PDF forms can be downloaded from these 3rd parties such as the government and used as report templates. These forms often include fields already embedded in the form layout, in this case the user is able to map the field names to XML data element names. At runtime the PDF form is merged with the XML data to create a filled copy of the original PDF form.

    29. Templates PDF Forms Templates PDF Forms (2) For partner documents such as invoices, purchase orders, etc that require a specific format for their layout, PDF forms can be used. Once the layout is designed, form fields can then be embedded in the document, these can then be mapped to the required XML data elements. At runtime the XML data is merged to create a filled PDF document. Templates PDF Forms (2) For partner documents such as invoices, purchase orders, etc that require a specific format for their layout, PDF forms can be used. Once the layout is designed, form fields can then be embedded in the document, these can then be mapped to the required XML data elements. At runtime the XML data is merged to create a filled PDF document.

    30. Templates - RTF Templates RTF RTF templates provide an easy to use interface e.g. Microsoft Word to create and customize report formats. Marketing departments can quickly take advantage of their existing marketing collateral, personalizing the final output for prospects and customers, generating high fidelity marketing materials. Contracts are very textual documents and require a period negotiation, rtf templates and outputs allow simple design of the contract template and the RTF output allows the two parties to update the contract document during the negotiation period. RTF templates lend themselves very well to financial reports, the layouts can be built very easily and are highly customizable. The RTF templates are internally converted to XSL-FO, at runtime the XSL is applied to the incoming XML data, the resulting object can then be converted to PDF, RTF or HTML outputs. Templates RTF RTF templates provide an easy to use interface e.g. Microsoft Word to create and customize report formats. Marketing departments can quickly take advantage of their existing marketing collateral, personalizing the final output for prospects and customers, generating high fidelity marketing materials. Contracts are very textual documents and require a period negotiation, rtf templates and outputs allow simple design of the contract template and the RTF output allows the two parties to update the contract document during the negotiation period. RTF templates lend themselves very well to financial reports, the layouts can be built very easily and are highly customizable. The RTF templates are internally converted to XSL-FO, at runtime the XSL is applied to the incoming XML data, the resulting object can then be converted to PDF, RTF or HTML outputs.

    31. Templates - Excel Templates Excel Many financial report consumers such as accountants use Excel extensively in their day to day work. Excel templates lend themselves to financial and business report. Excel outputs allow those consumers to check the data in Excel itself. The charting capabilities of Excel can also be exploited using the Excel templstes.Templates Excel Many financial report consumers such as accountants use Excel extensively in their day to day work. Excel templates lend themselves to financial and business report. Excel outputs allow those consumers to check the data in Excel itself. The charting capabilities of Excel can also be exploited using the Excel templstes.

    32. Templates eText Templates eText eText templates are a special type of RTF template that allow users to define EFT and EDI formats. These are very straightforward templates that look very similar to the document used to define the EFT/EDI file specification. At runtime these are converted to XSL and applied to the XML data to produce the flat text output file required.Templates eText eText templates are a special type of RTF template that allow users to define EFT and EDI formats. These are very straightforward templates that look very similar to the document used to define the EFT/EDI file specification. At runtime these are converted to XSL and applied to the XML data to produce the flat text output file required.

    33. Demonstration This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

    34. Steps Involved

    35. Define Data Logic

    45. Security PDF Security levels for Read only / Editable Copy Text Printable Password Protection Security XML Publisher allows the user to produce secure PDF output, with security levels covering: Read Only/Editable Copy Text Printable Password Protection Security XML Publisher allows the user to produce secure PDF output, with security levels covering: Read Only/Editable Copy Text Printable Password Protection

    46. Language Support XML Publisher ships with full set of Unicode Fonts Scalable Unicode font embedding Support for font mapping and font linking XML Publisher is alone in supporting CJK BiDi Unicode MLS Language Support In todays global economy the support for languages is paramount, XML Publisher ships with a full set of unicode fonts, a font mapping and sub-setting engine has been built; as the output is created the engine picks the font glyphs required for the languages used, these are then embedded inside the document as a new font. This ensures that the final output will contain the required fonts and no specific fonts are required on the printer. XML Publisher is alone in supporting: CJK BiDi Unicode MLS This compares favorably against other PDF engines.Language Support In todays global economy the support for languages is paramount, XML Publisher ships with a full set of unicode fonts, a font mapping and sub-setting engine has been built; as the output is created the engine picks the font glyphs required for the languages used, these are then embedded inside the document as a new font. This ensures that the final output will contain the required fonts and no specific fonts are required on the printer. XML Publisher is alone in supporting: CJK BiDi Unicode MLS This compares favorably against other PDF engines.

    47. Language Support Communicate with partners around the world in their languages 160 languages and 200 Territories (ISO Standards) Translate each template into 160 languages No dependency on the DB char set Utilize RTF or XLIFF for translation Language Support (2) XML Publisher allows users to create templates in 160 languages in 200 territories, there is no dependency on the database character set. Customers can use either XLIFF technology to have their templates translated or provide translators with the whole template, this is great advantage, allowing translators to translate templates in context.Language Support (2) XML Publisher allows users to create templates in 160 languages in 200 territories, there is no dependency on the database character set. Customers can use either XLIFF technology to have their templates translated or provide translators with the whole template, this is great advantage, allowing translators to translate templates in context.

    48. XML Publisher Better Information Faster Cheaper This presentation will give you an overview of the technology used in XML Publisher.This presentation will give you an overview of the technology used in XML Publisher.

More Related