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

  • Generating Native APIs
    By using the native API framework you can run standard QAD Enterprise Applications character programs on an AppServer and receive input from a dataset rather than from the user interface. In addition, the framework allows you to run character programs that have been customized using the QAD Integrated Customization Toolkit (ICT) or the .NET UI.
    Note: For details on customizing functions using the .NET UI, refer to Chapter 8, “Configurable Screens,” in User Guide: QAD User Interfaces.
    The .NET UI allows you to configure a screen to suit your requirements by disabling fields, setting default values, and so. If the modified function is supported by a native API, that function can be used in native API mode with the identical business logic. For example, if a QDoc contains a value for a field that has been disabled in the customized function, the value for the field will not be set in the API.
    Note: For a list of functions that are supported by native APIs, see Native APIs.
    Since configurable screens are configured by role, the system uses the role associated with the user ID specified within the QDoc.
    .NET Customization
    The .NET UI supports the following customizations:
    Disabled fields. These are supported by ensuring that the field in the request is always set to the unknown value so that the API determines what the value will be.
    Default values. These values are supported by ensuring that in the case of an Add operation, if the request field is unknown, the default value is put in its place.
    Required fields. These fields are supported by ensuring that the field in the request, if it is a character data type, is not set to blank. A post-processing step ensures that after the API has executed, required fields in the database are also not set to blank.
    Validation. Field validation is supported by allowing the customization class to validate a field and its value however it chooses.
    User fields. These fields are in the same database table as the other fields in the request, but are not part of the static API dataset. User fields are supported by copying the value from the request to the database as a post-processing step.
    Note: The post-processing step is an internal process rather than an operation that can be physically performed. This means there may be some limitations to your customizations.
    Example: You have a customization using ICT that updates pt__chr01 in frame A and runs a program when frame A finishes that uses the value the user entered in pt__chr01 to set another value. The additional fields are updated as a post-processing step outside of the API execution, and in the above scenario the value of pt__chr01 may not be set when the custom program is executed.
    New fields. These fields are supported by allowing the customization class to get and set the value of the new fields.
    Important: For the API to work correctly with .NET customizations—as well as ICT customizations—the .NET UI and/or ICT programs must be specified in the PROPATH of the session running the API.
    ICT Customization
    The ICT supports the same customizations as .NET except required fields and custom navigation. In addition it supports the following customizations:
    Shadow tables
    Program modification using tags
    Note: Any external program that is executed by the ICT process must also be modified to work in API mode.
    Some ICT customizations are based on ENTRY, LEAVE, and GO triggers. Since these triggers never occur in API mode, customizations involving custom program execution is performed as part of the post-process step. One problem that may arise is that these triggers can be frame and field based, and if the field appears in more than one frame then it is possible to run a different program depending on the frame it is in. This situation will have to be managed in the custom program itself.
    Native API Process Flow
    Creating and using native APIs consists of several steps:
    Customize your character program(s) as required using either .NET UI or ICT.
    Configure the controllers.xml and customizations.xml files as required. See the Setting Up Customization.
    If additional fields have been added to a function, a new schema must be generated for the role. Upload the new schema files to the QXI server or to a file.
    Specify the .NET UI and/or ICT programs in the PROPATH of the session running the API.
    Setting Up Customization
    If you are changing the response schema file name, you must edit the controllers.xml file. Also, if you do not want to have customizations turned on, you must edit the customization.xml file. Both of these files are located in the qxtendadapter/config folder.
    The controllers.xml file lists all available native APIs. Each API to be used must specify the name of the API (for example, maintainMasterComment), the name of the customization class, the name of the request schema and response schema (both optional), and API program name, as in the following example:
    <?xml version="1.0"?>
    Each type of customization must be defined in customizations.xml, as in the following example:
    <?xml version="1.0" encoding="UTF-8"?>
    <name>.Net UI Customizations</name>
    <name>ICT Customizations</name>
    where name is the name of the customization and class is the name of the class for the customization. If customizations will not be used, these can be commented out.
    Note: Commenting out ICT customizations that are not required will marginally improve system performance.