NLINK Deployment. White Paper

Transcription

1 NLINK Deployment White Paper

2 Junot Systems Corporation. All rights reserved. The information contained in this document represents the current view of Junot Systems Corporation on the issues discussed as of the date of publication. Because Junot Systems must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Junot Systems, and Junot Systems cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. JUNOT SYSTEMS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. NLINK, CoNNectors and extenders are registered trademarks of Junot Systems in the United States and/or other countries. NLINK is protected in the US and other countries by the following patents; 6,411,963, 6,466,934 and 6,513,044. Other product or company names mentioned herein may be the trademarks of their respective owners.

3 NLINK Deployment White Paper Introduction... 1 NLINK Server... 2 Connectivity... 2 NLINK Engine... 3 Enterprise Features... 3 NLINK Configuration Module... 3 Meta-database... 5 NLINK Configuration... 6 The Configuration Process... 6 NLINK Configuration Components... 7 Mapping and Transformation... 7 Working Store... 8 Business Logic... 9 System Properties Advanced Configuration Features Wizards Validation Find, GoTo and WhereUsed NLINK Debug Module Auto-Doc Module Transaction Versioning Concurrent Configuration The NLINK Advantage A Real World Example The Traditional Approach... 21

4 The NLINK Approach Summary Glossary... 25

5 PAGE 1 Introduction NLINK is a patented, field proven and SAP certified Enterprise Application Integration (EAI) software product suite that is quick and easy to deploy. NLINK significantly reduces the time and expense of integrating applications by providing a standardized and repeatable integration process. Integration is completely configuration-based through an intuitive visual environment that requires no end-user programming. This allows functional business users to perform complex integration tasks and provides a scalable and maintainable integration solution as business processes and installed applications change over time. NLINK has been designed from the ground-up to provide real-time communications between disparate applications both within and across enterprises and has deep functional capabilities when it comes to SAP integration. Junot Systems not only provides the NLINK product suite it also provides its customers and partners with access to its in-house technical and functional SAP experts backed by our in-house SAP R/3, SAP ECC and Oracle Applications systems. No matter how technically advanced and simple to use the integration tool may be, customers and partners still need access to functional and technical integration experts in order to refine and rationalize their integration project requirements. In almost all cases, NLINK is required to bridge the gap between the desired business processes and the functional capabilities of the systems that must play a role in those desired process. The NLINK product suite facilitates and simplifies the implementation of the business processes, the Junot Systems functional and technical experts work with our customers and partners to design the most appropriate and efficient solution possible. This white paper describes the process and benefits of an NLINK deployment and seeks to give the reader a better understanding of the steps needed to complete an NLINK integration project. It will show how quick and easy it is for functional business users to perform what would otherwise be an impossibly complex integration task. In order to understand the NLINK configuration process it is helpful to first review some high-level concepts of the NLINK Server and NLINK Configuration Module (NCM) architecture. For more details beyond the brief overview given here, please refer to the NLINK Architecture white paper.

6 PAGE 2 NLINK Server NLINK is an event-driven transaction-based system, built around a hub-and-spoke architecture. Conceptually, the architecture of the NLINK Server can be depicted as follows: Figure 1.1 NLINK Server Architecture There are three logical components to the NLINK Server architecture: Connectivity In general, open industry standards and communications methods (such as XML) are supported through NLINK extenders while support for a particular vendor's proprietary technology (e.g. integration to SAP) is supported through NLINK CoNNectors. NLINK supports a wide range of CoNNectors and extenders and has no favor or preference to any one of them, unlike other tools such as BizTalk which are predicated upon the use of XML. This technology independence allows NLINK integration projects to provide the optimal integration solution on a case-by-case basis. Each application that has access to NLINK is called, in NLINK terminology, an External System. The NLINK Server is connected to external systems through CoNNectors and extenders.

7 PAGE 3 For a detailed description of the NLINK CoNNector and extender architecture please refer to the NLINK Architecture white paper. NLINK Engine The NLINK Engine is the core component of the NLINK Server and contains all of the logic for the mapping, routing, transformation and business logic that is applied to the data received from the external systems. The configuration process (performed using the NLINK Configuration Module, or NCM) defines how the NLINK Engine will map, route, transform and process the data it receives from the external systems. Configuration of the NLINK Engine is the focus of this white paper. Enterprise Features NLINK s enterprise-class features are grouped into the four categories of reliability, scalability, flexibility and manageability. They include such things as store-and-forward, replication, centralized administration and many more. These features are wrapped around the NLINK Engine and are either enabled or disabled for an NLINK deployment rather than on a transaction-by-transaction basis. For a full description of the NLINK enterprise-class features please refer to the NLINK Architecture white paper. NLINK Configuration Module The NLINK Configuration Module (NCM) provides a Graphical User Interface (GUI) to the configurer of the NLINK Server. The configurer need not be a software developer or an IT expert, but rather a functional business specialist who is familiar with the logical business transactions required for the particular customer. This person requires a simple to use, efficient, and flexible user interface that abstracts the complex data processing issues and represents them in business terms. Business users should not be required to understand such things as network programming, object-oriented design and development techniques or any software development language such as Java, C# or C++. The NCM allows business users to: Configure the Workset database structure (fields, tables and their relationships to each other); Create Message Formats and Maps, to control data exchange with the External Systems; and Define Events that set the boundaries of NLINK transactions. Define Actions and Action Series that apply the required business logic.

8 PAGE 4 Figure 1.2 The NCM The NCM contains many advanced features that make the NLINK configuration process easier, faster, and more accurate than any competing EAI product on the market today: Wizards simplify and accelerate the NLINK configuration process. Wizards put the business user in the context of the business process and automate the configuration process as much as possible. All of the CoNNectors and extenders supported by NLINK come with at least one Wizard. Some of the more complex systems, such as SAP R/3, come with several NLINK Wizards. Validation allows the end user to run the same meta-database validation routines that the NLINK Server runs at start-up. The results of the validation are presented as errors, (configurations that will not run), and warnings (configurations that may produce unexpected results). The validation results support the GoTo function so that the end user can immediately move to the appropriate place in the configuration to perform any necessary corrections. Find, Where Used and GoTo each allows the end user to simplify and speed the configuration process. Even though the configuration process is greatly simplified through each of the features outlined in this section, any real-world integration scenario requires a necessarily complex set of business logic. The Find feature allows the end user to search for specific items contained within the configuration. The Where Used option shows the links and dependencies that any one component has

9 PAGE 5 in the configuration. And the GoTo feature allows data that is presented to the user in a number of results dialogs to have hot-links to their actual location in the metadatabase. The NLINK Debug Module (NDM) is used in conjunction with the NCM to view and analyze Workset dumps during the configuration process. During the configuration process it is sometimes useful to be able to examine the data contained within the NLINK Workset in conjunction with the settings and values of the Actions performing the business logic. The NDM allows the user to perform this analysis. Transaction Versioning provides the ability to version control configured business transactions from the NLINK meta-database. The end user can select subcomponents of their configuration to extract and save separate from the main metadatabase. This allows end users to extract reusable components and then store them in a commercial version control system. When a new integration project starts the users can browse the version control system for reusable components that may be appropriate for the new project. In this way, end user can create pre-built configurations and so provide off-the-shelf solutions. Concurrent Configuration is the ability of NCM users to efficiently and effectively work as large teams developing the configuration for a single NLINK deployment project. By designing the NCM to easily support large configuration teams, NLINK deployments can in many cases be accelerated by simply adding more resources. Meta-Database The NLINK meta-database stores all NLINK configuration information, including system settings (such as connection information for various external systems) and transactionspecific configuration information. The contents of the NLINK meta-database are controlled completely through the use of the NLINK Configuration Module.

10 PAGE 6 NLINK Configuration To better understand the logical steps required to successfully complete an NLINK configuration project we need to review NLINK s approach to integration. The Configuration Process Figure 2.1 NLINK Configuration Process An example NLINK configuration process is graphically depicted above. This process flow illustrates the exchange of a purchase order from one system, (External System 1) to another, (External System 2).

11 PAGE 7 NLINK Configuration Components At its simplest level the objective of the integration exercise is to convert data coming into the NLINK Server into NLINK s internal format (and storage area) where it can be efficiently manipulated. Once the data has been manipulated to the extent required by the business process it needs to be converted into the format(s) required by the system(s) or application(s) that will be receiving the outbound data. NLINK manages this integration process through the data processing engine that sits at the heart of the NLINK Server which is made up of the following logical components: Figure 2.2 The NLINK Engine Mapping and Transformation Mapping and transformation are the fundamental data manipulation processes that occur in order to take external data and convert it into NLINK s internal in-memory working storage, where it can be further manipulated and processed. Data must be mapped from

12 PAGE 8 the Workset format into the external system s native format before it can be sent from the NLINK Server to the external system. From NLINK s perspective, Mapping and Transformation has three components: External Systems External systems are any software application or product (commercial or legacy) that is connected to the NLINK Server. Every NLINK CoNNector and extender has an external system configuration type that is supplied by Junot Systems and is non-editable. Each physical device that NLINK connects to requires a unique instance of the CoNNector and extender to be configured. This configuration is trivial and includes such things as the network name (or IP address) of the device, the version of the external system software (such as SAP R/3 4.6C) and any external system-specific login parameters, if necessary. Message Formats Message Formats represent the layout of a message from a particular external system. Knowledge of the layout is used to define how to parse the message. Configuration of the Message Format is the act of describing the incoming data layout in terms of tables and fields. This is a mechanical rather than intellectually taxing assignment. In order to speed this process Wizards are provided with every NLINK CoNNector so that this mundane step can be automated in as many cases as possible. Maps Maps tie the data coming in from the Message Format into NLINK s local working storage known as the Workset database. Configuration of the Maps consists of converting (or mapping ) the table and field structure used to define the incoming message to the table and field structure used to define the Workset. As in the case of Message Formats, this step is a rather mechanical process that the NCM is frequently able to automate through the use of an appropriate Wizard. Working Store NLINK s temporary working storage area is known as the Workset database. Workset Database The Workset is a proprietary, memory-resident store for the data during the life of an NLINK transaction. There is no pre-defined structure to the Workset. It can be configured to fit any particular business need. There are three parts of the structure to define: fields, tables and relationships between tables. There can be as many or as few fields and tables

13 PAGE 9 as needed. Since the Workset resides completely in memory, access to and manipulation of the data is extremely fast. Configuring the Workset consists of defining the internal layout of the data (tables and fields) as it will be stored within NLINK. The optimal layout is driven by the kinds of business logic that will subsequently be applied to the message data. So long as all of the possible data fields that can be present in a message are given placeholders within the Workset database there is really no right or wrong way to define the Workset layout. There are simply more efficient or less efficient Workset layouts depending upon the data manipulation requirements dictated by the specific business process being configured. Business Logic Business logic is defined, by NLINK, as any manipulation above and beyond the mapping and transformation processing that is performed on the data. Business logic is implemented within the NLINK Server through Events and Actions. Action Series Actions are discrete units of data processing that are defined within the NLINK Server through configuration. Once data is received from an external system, an Action (or more correctly, an Action Series) can be applied to the data to perform a logical business process. Any number of Actions can be linked together, to form an Action Series, and Action Series can branch conditionally to execute different processing steps depending upon validation rules. This approach creates an extremely flexible and efficient configuration-based processing engine.

14 PAGE 10 Fig 2.3 The NCM Action Series Tab The configuration of Action Series requires knowledge of the business process to be implemented and the ability to apply a logical thought process to its decomposition into building blocks that match the NLINK Actions. One or more Action Series can be associated with a single Transaction, and an Action Series can call another Action Series. This allows configurers to create reusable logical functions (such as standardized error handling) and then call them as an Action Series at the appropriate part of the processing sequence. These reusable Action Series can be shared across many Transactions.

15 PAGE 11 Events Events act as triggers that stimulate the NLINK Server to perform some set of preconfigured functions, (or in NLINK terminology, Action Series). Generally, and most simply, the event is the receipt of a message from an external system that triggers the NLINK Server to process the received data in some way. Every message received by NLINK is associated with a unique Event ID. Events can also be scheduled through the use of the Scheduled Event Wizard. Fig 2.4 The NCM Event Tab and the Scheduled Event Wizard The NLINK Event configuration process is a simple matter of associating the event key for a particular incoming message with one of the Action Series that has been configured.

16 PAGE 12 System Properties System properties are configurable parameters that are applied to all of the business transactions configured into a specific NLINK deployment. They include such things as; whether Automatic Audit Trail, Store & Forward or Error Recovery is turned on or not; the reporting threshold for NLINK system messages; the name and location of the NLINK Transaction Log; and several other system-wide parameters. Fig 2.5 The NCM Global Properties

17 PAGE 13 Advanced Configuration Features Wizards The NCM contains many advanced features that make the NLINK configuration process easier, faster, and more accurate than any competing product on the market today. Junot Systems continuously innovates the integration process and provides the following unique features and functions not found elsewhere. Wizards are configuration aids that are layered on top of the basic NCM product that provide additional efficiencies in the speed, ease and accuracy of configuration. Wizards put the configurer in the context of the particular business transaction and seek to remove as much of the application-specific knowledge required to complete the Map and Message Format configuration as possible. Any repetitive configuration task is a good candidate for an NLINK Wizard, and all NLINK CoNNectors and extenders are provided with an accompanying Wizard. Since Wizards significantly reduce the amount of external system knowledge required to configure an interface they have the added benefit of allowing novice NCM users to become productive sooner than would otherwise be possible. Fig 3.1 The NLINK Advanced Data Collection (ADC) Wizard For example, the ADC Wizard provides a drag-and-drop method for quickly creating RF bar coding gun screens. Without the ADC Wizard it would be necessary to create bar coding gun screen layouts manually from the Actions provided with the NLINK ADC CoNNector, which would be an unnecessarily laborious and time-consuming process.

18 PAGE 14 Validation The software technology used to create NCM Wizards allows Junot Systems to develop, test and release new Wizards asynchronous to the regular NLINK product releases. This approach allows continuous innovation and improvements to the speed of implementation of the NLINK integration projects. Validation allows the end user to run the same meta-database validation routines that the NLINK Server runs at start-up. The results of the validation are presented as errors, (configurations that will not run), and warnings (configurations that may produce unexpected results). Fig 3.2 The NCM Validation Results Dialog Note that the validation results support the GoTo function so that the end user can immediately move to the appropriate place in the configuration to perform any necessary corrections.

19 PAGE 15 Find, GoTo and WhereUsed Find, GoTo and WhereUsed each allow the end user to simplify and speed the configuration process. Even though the configuration process is greatly simplified through each of the features outlined in this section, any real-world integration scenario requires a necessarily complex set of business logic. The Find feature allows the end user to search for specific items contained within the configuration. Fig 3.3 The NCM WhereUsed Results Dialog The WhereUsed option shows the links and dependencies that any one component has in the configuration. And the GoTo feature allows data that is presented to the user in a number of results dialogs to have hot-links to their actual location in the meta-database. NLINK Debug Module The NLINK Debug Module (NDM) is used in conjunction with the NCM to view and analyze the runtime contents of the NLINK Workset during the configuration process. During the initial configuration phase it is sometimes useful to be able to examine the data

20 PAGE 16 Auto-Doc Module contained within the NLINK Workset in conjunction with the settings and values of the Actions performing the business logic. The NDM allows the user to perform this analysis. The NLINK Auto-Doc Module automatically generates either Hypertext documents or flowchart-style drawings that represent the configuration of an NLINK integration project. Since these hypertext documents and flowchart-style drawings are created from the NLINK configuration itself, they are always accurate and complete. Fig 3.4 The NLINK Auto-Doc Module FlowChart Output The NLINK Auto-Doc Module can be used for a variety of purposes: Use the Visual Component as a Diagnostic and Customer Support Tool, as a Design Aid or as an Implementation Guide. Use the Hypertext Component for Knowledge Capture and Transfer, Archiving and Change Tracking or as an aid for Customer Support Troubleshooting.

21 PAGE 17 Transaction Versioning Transaction Versioning allows configurers to extract a business process from the NLINK meta-database and store it in a version control system, such as Microsoft s SourceSafe. It also allows the insertion of previously configured business processes (transactions) into an existing NLINK meta-database. Fig 3.5 The Transaction Versioning Wizard This is a very powerful feature that provides many benefits to the end user: First, it allows the end-user to create a repository of version controlled business transactions so that an audit trail of the integration transactions can be created and maintained as business processes and systems change over time. If for any reason it becomes necessary to revert to a previously configured transaction it is a simple matter to extract the old transaction from the version control system and insert it into the NLINK meta-database. Second, it enables the end-user to create a library of pre-built business processes. These processes can be rapidly deployed as needed, greatly speeding up the time required to deploy NLINK. Clearly, the knowledge required to modify a pre-built transaction to fit current needs is far less than that required to create it in the first place. This means that NLINK configuration teams can be built from a mixture of experienced and inexperienced business professionals.

22 PAGE 18 Third, since the NLINK transactions are self-documenting, transaction versioning allows end-users to create an external fully documented repository of business processes. Concurrent Configuration NLINK is unique in that it has been specifically designed to facilitate concurrent configuration by large teams of configurers. This feature allows large-scale integration projects to be centrally managed, coordinated and accelerated through the deployment of additional resources. This differentiates NLINK as the only commercially available EAI product on the market today that can be effectively and efficiently used to integrate largescale projects. Concurrent configuration of NLINK is supported through numerous methods. First and foremost is the creation of an implementation methodology by the Junot Systems Services group. This methodology defines the best practices and approaches that should be used by NCM configuration teams in order to gain maximum efficiencies. The methodology builds upon features embedded in the NLINK Server and NCM which include, but are not limited to: Transaction Versioning; creation of reusable configuration components; the ability to copy and move logical components of a configuration between transactions; the ability to organize large numbers of transactions easily within the NCM, and many others. Without a product that supports concurrent configuration integration projects cannot be completed faster simply by adding resources, which effectively limits the amount of control project managers have over the integration project.

23 PAGE 19 The NLINK Advantage The following section provides a detailed description of a specific SAP barcoding integration problem that can be quickly and easily solved by NLINK. The description of the solution will make use of concepts developed earlier in this white paper. This real world example is then used to contrast the high-level differences between the traditional approach of developing a custom-coded solution to solving the integration problem with NLINK. The choice of SAP as the primary system is a good one for many reasons. First, it is by far the most widely used Enterprise Resource Planning (ERP) system in use today. Second, it is a fiendishly complex system to understand, both from a technical and a functional perspective. Third, it is a system that is built upon the premise that each business is unique and so allows and encourages end-user customization, making virtually every installation unique. Finally, it is a mission critical system that requires specialized (and expensive) ongoing administration and support which often forces an operational requirement of integration without modifying or installing anything on the SAP system. A Real World Example The SAP barcoding system described in this section can be represented as follows: Figure 4.1 Network Topology The NLINK Server is deployed here on a Windows Server 2008 workstation on a local area network (LAN). Also on the LAN is a SAP ECC 6.0 installation physically deployed

24 PAGE 20 across multiple servers but represented logically as a single SAP instance. The bar code scanners are connected to the LAN via an RF connection and a wireless router. The SAP Barcoding Transaction The specific barcoding business transaction to be implemented in this discussion is to scan a part in the warehouse, using the RF-based bar code gun, and post a query to the SAP system to determine the current inventory levels. The result of the query is then displayed on the bar code gun screen. This business transaction is shown graphically below: Figure 4.2 SAP Barcoding Business Transaction Example The diagram shows a screen from the bar code scanner on the left-hand side. When a warehouse inventory item is scanned, and the F1 key pressed, the bar code scanner formats a message and transmits it (via radio frequency) to the NLINK Server. This message is represented as the Scanned Data arrow-box going from the scanner to the NLINK Server, in the middle of the diagram. Upon receipt of the information by NLINK, the data is parsed, formatted, mapped and stored in the Workset Database. The transaction has had the F1 Event tied to an Action Series that results in an SAP Query and so, upon receipt of the event, NLINK maps and formats the data into an SAP query, and issues the query to the SAP system. The SAP Query arrow-box represents this process. The SAP system receives the query message, processes it, and returns the resulting data set back to the NLINK Server. The data contains a material, quantity, and unit-of-measure, and is represented by the SAP Data arrow-box. Upon receipt of the SAP message, NLINK formats and maps the message data into the Workset Database and associates the Send Message Action to the Event. This results in the data being mapped and formatted into a

25 PAGE 21 barcoding-friendly message, which is transmitted to the bar code scanner. Upon receipt of the message, the bar code scanner renders the screen showing the data to the operator. It should be noted that in this specific example not only is the data mapping, translation, and business logic being configured through the NLINK meta-database, but also the appearance and layout of the RF bar coding gun screens is part of the NLINK configuration. Clearly then, it is possible for NLINK to completely eliminate any custom software development in any integration project. In a real-world integration scenario the NLINK Server would be configured to take advantage of its many other features to create a truly robust enterprise-quality solution. Local Validation would be configured into the business transaction to ensure that complete and correct data is passed to the SAP system. By providing local validation within the NLINK Server before the data is passed to SAP we can eliminate unnecessary and expensive round-trip requests to the SAP system. If incorrect data is passed into the NLINK Server from the bar code scanner, it can be validated and immediately routed back for correction. Replication could be configured so that frequently used data from the SAP system is asynchronously retrieved and stored local to the NLINK Server, providing performance improvements by removing the need for unnecessary round-trip requests to the SAP system. Store-and-forward may be configured to allow automatic re-connection and resumption of transaction processing after an unforeseen SAP system outage without any loss of data. NLINK s Store and Forward capability ensures that each message to SAP is sent once and only once, in the correct sequence thus ensuring transactional integrity. Security would be enabled so that end users of the bar code scanners would be required to login via their guns before starting. The NLINK Server then uses the builtin capabilities of the Windows OS to authenticate and authorize users and can present only the appropriate levels of access warranted by each user. For more detailed information regarding the enterprise features of the NLINK product suite please refer to the NLINK Architecture white paper. The Traditional Approach The traditional approach of developing a custom coded solution to connect a barcoding application to an SAP system requires considerable knowledge and custom software development just to get basic connectivity, never mind implementing some of the more advanced features that would be mandatory in any real-world mission critical project.

26 PAGE 22 Knowledge A great deal of knowledge required to implement a custom coded integration solution. Some of the knowledge required is summarized below: 1) Learn several programming languages, such as C++, Java, VB and SAP s ABAP. 2) Learn several programming techniques and concepts, such as object-oriented analysis and design, agile programming, and networking. 3) Learn the programming interface and idiosyncrasies of the particular SAP Barcoding application. 4) Learn the programming interface and idiosyncrasies of the various SAP communications methods, (such as RFCs, BAPIs and IDOCs). 5) Learn the business logic behind the transaction(s) and determine which of the SAP communications methods (RFCs, BAPIs and IDOCs) should be used to support the business process. Then, impart all of this knowledge to the IT staff. 6) Find someone who understands both the business process and software development issues to manage the project. Software Development The software development effort needed to perform a custom coded solution is summarized below: 1) Define requirements for, then analyze, design, develop and test the communications interface between the two external systems. 2) Define requirements for, then analyze, design, develop and test the implementation of the business logic into the application that connects the two systems together. 3) Document the solution well enough so that success in maintaining the solution does not depend on any individual members of the IT staff. 4) Maintain and improve the solution when new versions of the barcode scanning hardware and SAP applications are released and deployed. As an example, bear in mind that SAP has routinely made changes to its object model and reference tables when they launch new versions of SAP. 5) Continue to train the IT staff that your solution has now become dependent upon so that they are familiar with the new technologies and approaches employed by the data collection devices and the SAP system. For example, the

27 PAGE 23 Clearly, the custom coded solution approach is an expensive, complex, error-prone and time consuming undertaking for even the most sophisticated and well staffed of enterprises and IT departments. Further, it creates a hidden cost by providing a point solution that requires a high ongoing investment of both time and money to maintain and enhance the integration solution as needs arise. The NLINK Approach The NLINK approach to solving this problem is much simpler and faster than the traditional approach because it requires only the following configuration process to take place. Note that none of these steps requires any software programming of any kind, but merely data entry through the graphical NCM. Figure 4.3 NLINK Configuration Process Flow In the case of Automatic Data Collection to SAP integration, Junot Systems provides a further level of simplification through the pre-built NLINK ADC to SAP Solution. The NLINK ADC to SAP Solution combines the NLINK Server, the NLINK CoNNector for SAP and the NLINK ADC CoNNector and bundles them with a set of pre-built, off-the-shelf data collection business transactions that end users can choose from. In this case, SAP can be completely integrated to a variety of commercially available data collection devices in a matter of hours. The NLINK solution requires no software programming effort or IT resources, can be executed completely by a business professional, is extremely fast (compared to a custom coded solution), and is simple and cheap to maintain and extend. Furthermore, since NLINK is an enterprise-class product the solution developed through NLINK is reliable, scalable, flexible and manageable.

28 PAGE 24 Summary NLINK provides a comprehensive solution to the Enterprise Application Integration problem by significantly reducing the time and expense of integrating applications and providing a standardized and repeatable integration process. Integration is completely configuration-based through an intuitive visual environment that requires no end-user programming. This allows functional business users to perform complex integration tasks and provides a scalable and maintainable integration solution as business processes and installed applications change over time. Junot Systems further simplifies the deployment of NLINK by providing a number of out-ofthe-box solutions, such as the NLINK ADC to SAP Solution the NLINK OPC to SAP Solution and the NLINK MES to SAP Solution. These solution sets not only provide the patented, field proven and SAP certified NLINK technology, they also come with pre-built transactions already configured that simply need to be tweaked for the specific deployment scenario. NLINK integration technology, pre-built NLINK solutions, access to Junot Systems technical and functional experts, (backed by our in-house SAP R/3 and SAP ECC systems), are just some of the benefits customers and partners reap when collaborating with Junot Systems for their integration needs.

29 PAGE 25 Glossary Action Series Actions are discrete data processing functions that are uniquely defined within the NLINK Server. Once data has been received from an external system, an Action, or a series of Actions (an Action Series) can be applied to the data to perform a logical business process. Any number of Actions can be linked together, and actions can branch conditionally to execute different processing steps depending upon validation rules. This approach creates an extremely flexible and efficient configuration-based processing engine. External Systems External Systems are each repository of data or computer system that NLINK can communicate with. Maps Maps tie the data coming in from the Message Format into the working storage known as the Workset database. (Message) Formats Message Formats define how to parse (or create) a message for a particular external system. Each message format represents a particular exchange of data between NLINK and the external system, (e.g. Query a list of part numbers). Meta-database The Meta-database stores all NLINK configuration information, including system settings (e.g., connection information for various external systems) and transaction-specific configuration information. Workset Database The Workset is a memory-resident store for the data during the life of an NLINK transaction. There is no pre-defined structure to the Workset. It can be configured to fit any particular business need. There are three parts of the structure to define: fields, tables and relationships between tables. There can be as many or as few fields and tables as needed. Since the Workset resides completely in memory, access to the data is extremely fast. The structure of the Workset is defined through the NLINK Configuration Module (NCM).