In order to bring you the best possible user experience, this site uses Javascript. If you are seeing this message, it is likely that the Javascript option in your browser is disabled. For optimal viewing of this site, please ensure that Javascript is enabled for your browser.
Login  |   Cloud ERP  |   Home  |

  •     QAD Glossary

  • QAD Enterprise Edition
    QAD Enterprise Edition
    In the past, QAD released the core ERP product with such versions as eB2, eB2.1 and QAD 2007.
    New Financials Module
    The previous financials module was completely rewritten. None of the earlier code or schema remain.
    The architecture of the code is also new. It was written in a business-object / SOA style.
    New Financials Integration Components
    The first level is the .NET UI with this plug-in model. It provides a perfect home for an integration point.
    The Finance product was already written in a native .NET User Interface. It is the only interface in the product; there is no character interface for Finance.
    As a result, there are already the outer wrapping applications for things like logging in. The first step was to pull that out into its own, really to conform to the plug-in interface. At that point, the plug-in interface was being defined and really used the Finance product as the prototype model for that.
    That is the first level of integration. It is similar to putting the plug-in interface around the Finance product and allowing it to be launched from .NET UI menu system.
    QAD Reference Architecture
    Encapsulation of Services:
    Each layer will offer a number of clearly defined services. These services have interfaces that describe how the services can be used.
    For example, on the presentation layer, the AppShell offers a plug-in architecture of a framework that calls/combines services.
    For example, on the app layer, specific components provide central functionality for the backend, like Session (for session management), Transaction (for logical transactions), Translations, and so on. These components have clearly defined interfaces, that can be called by any external consumer (whether it is the UI, or another party that integrates with the application core services).
    For example, on the data access layer, the connection to the database, the possible queries and updates are implemented in a component. This component has a clear interface and is used by all business components in the system to get to the data. This brings a powerful level of abstraction to the application.
    Responsibility of each layer:
    Presentation: User interaction. Provide the user access to the data (show the data on the screen), navigation in the system, provide the application menu, integration of the application on the client/UI level, and so on.
    Web: Transport Mechanism
    Application: Access to the data, calculation of data, validation of data, updates in related objects, query capabilities, meta information about objects, and so on.
    Data access: Data retrieval and data update.
    The layering of the application allows components to more easily to evolve to other technologies and to be more independent. UI technology is moving much faster than the technology used for the business logic. This is why it is very important to have the separation in layers and for the access to the services in the layers to always go through predefined interfaces.
    It is also important that the application functions follow a limited number of application patterns. This allows for easier customization and extensions of the standard functionality at a later stage.
    Note: Technical or performance constraints may, in specific areas, override the QRA.
    QAD Reference Architecture 2
    This architecture is fully implemented for Enterprise Financials.
    The Standard Edition / Core ERP codebase still uses the legacy MFG/PRO architecture with the Presentation and Web Layers wrapped around it.
    Enterprise Financials
    It is important to have a uniform way to pass object data between the layers. As soon as a business component is instantiated, and an object from the database is “loaded”, all relevant information is stored in the object dataset. The object dataset is the only way of passing the object state / information between the different layers.
    Besides being used as a transportation vehicle, the dataset also lends its structure to external parties wanting to integrate with the business application. For example, when the business application exposes objects through configured events, the data that is published always has the same format, which is defined by the XML schema of the object dataset for the specific component. Also, when data is loaded, the business application backend requires that the data be in the official object dataset format.
    What’s New?
    What’s New? 2
    Standard Edition versus Enterprise Edition