The NetWeaver Runtime Framework is a flexible tool for building standalone NetWeaver applications, primarily NetWeaver-guided report generators. The ultimate product of the application is a report in the user's choice of format (.pdf, .rtf, etc.). Internationalization is built in: the framework can change both interface and content languages on the fly with no limits on the number or type of languages (of course, it is up to the application builder to include the appropriate language content.

Developer's note: While the NetWeaver Runtime Framework still exists, it has been superseded by a more versatile multi-platform framework. The new framework requires access to proprietary source code to build runtime applications, so please contact the developer if you are interested in it.

A NetWeaver runtime framework application consists of a series of sections, each with its own role. The sections can be organized any order. NetWeaver will make sure it has the data necessary before moving to the next section.

A series of static pages. Generally these pages consist of instructions for following sections.

A data section is a series of dynamically determined data entry pages. The order of the pages is determined by current data needs with the most needed data first. Data is only requested if it is needed for the following sections. Each data need has its own page for data entry. Pick lists are generated on the fly. Data is validated before acceptance. Any documentation with the data need has a link to it on the page.

A series of dynamically generated pages whose content is based on the state of the knowledge base.

dynamically selected “snippets” to be included in a report. The state of the knowledge base determines which snippets to present and how to rank them. User input can also be enabled.

A typical report generator application might be assembled of the following sections (details follow):

• Introduction
• Initial data collection
• Summary
• Instructions
• Follow up data collection
• Report building

A “message” section to introduce the application to the user and provide initial instructions.

Message sections are simply a series of one or more static pages presented in sequence.

A “data” section to collect the immediate data needs for the following summary and report sections.

Data sections control the “asking” of questions. NetWeaver determines data requirements for the section by the checking the following summary and report sections. These data requirements are then evaluated for their relative influence and asked in that order. Often, as questions are answered, some data are no longer required and may not make sense to ask. NetWeaver will not ask these questions.

A “summary” section providing dynamic analysis of the current conditions.

Summary sections are controlled by NetWeaver dependency networks.

Another “message” section to explain to the user how to use the following data collection and report builder sections.

Another “data” section to collect whatever data is yet needed for the decision making process in the report builder.

A “report builder” section to assemble the final document.

Report builder sections present appropriate content snippets for the user to chose from. The content presented to the user is filtered by NetWeaver dependency networks. Only the content whose dependency networks meet the defined conditions and also have sufficient data are presented to the user. Additionally the content choices are ranked in the presentation so the user can see not only all possibilities but also which of those are the best fit for the situation. Provisions can also be made for direct user contribution so that the user can input original content.

As the user selects content it is assembled into a word processing document.

All textual content within the framework, the databases, and NetWeaver itself are stored in Unicode character encoding. Unicode character encoding ensures that all characters, regardless of language, have a unique representation. This means languages such as Russian, Korean, and French can all be correctly displayed along side of each other.

All report content is stored in XHTML. XHTML is the successor to HTML and includes XML support. XML is eXtensible Markup Language.

CSS - cascading style sheets are employed to control all formatting and most of the presentation. This is standard practice to isolate the presentation of a document from its content. Due to limitations in some of the third party software used for rendering XHTML documents not all layout depends on CSS, notably tables are used in some cases for positioning of content. See css for a listing of ids and classes used.

The framework generates content (in XHTML) through the use of recursive XML tags. The tags are used to look up content from the content database (see below). The content can, and often does, have embedded XML tags of its own. When these embedded tags are encountered they are recursively process in the same way until all tags are processed. This means recurring content such as titles or descriptions can be defined once and used many places.

The content database is an object oriented database featuring inheritance by object hierarchy and language. What this means is that database queries are first searched by item, section, then application. Within each object the database is searched by the current language choice, the default language (English), and then the framework's defaults. See tags for a listing of the default tags.

Say a tag of 'XHTL_PAGE_INTRO' is requested while in a message section and the chosen language is Russian (RU); the database will search for the associated content for that tag in the following order until a matching entry is found:

• Search within the item (in this case the current page for the message section)
  • Search for a match in the RU entries
  • Search for a match in the default language entries
  • Search for a match in the framework's built in default entries
• Search within the section (the message section)
  • Search for a match in the RU entries
  • Search for a match in the default language entries
  • Search for a match in the framework's built in default entries
• Search within the application's global entries
  • Search for a match in the RU entries
  • Search for a match in the default language entries
  • Search for a match in the framework's built in default entries
• Search for a matching built-in function (there are numerous built-in functions to generate lists and such)