Extension Modeler

Use the Infor LN Extension Modeler to add the logic around CDFs and how to tailor standard components.

This list shows the extension points for Infor LN:

  • Domain
  • Table
  • Report
  • Session
  • BOD / BDE
  • Menu
  • Process

In the Extension Modeler, you can set properties and hooks for those components. The implementation of the extension point for one component is called an extension. With an extension built for an extension point you change the behavior of a component. For example, by creating an extension for a session you can add additional fields to that session.

LN’s extensibility is built upon LN’s pluggable architecture. The standard application components of LN are plugged into the sockets of the runtime layers, which perform all common tasks, such as database access, screen handling, etc. Extensions are additional plugs into the runtime layers; sometimes, an extension can also handle as an adapter.

You can find the Extensibility sessions in Tools > Application Extensibility

This diagram shows this architecture:

../images/image1.png

  1. The LN Runtime layer (bshell) runs the LN programs and handles all RDBMS and operating system actions.
  2. The LN Tools layer is responsible for all common tasks regarding tables, screens, reports, BODs, and BDEs. This layer has several sockets where the Application layer can plug-in with properties and hooks into to perform the specific application functionality. For the Extension layer, additional sockets are available in the Tools layer.
  3. The Application layer has a set of standard components that have properties and pieces of code. This results in the desired behavior of the DAL, 4GL, BOD, BDE, and Report engines.
  4. The Extension layer has a set of components with properties and pieces of code. This causes different behavior or results in the DAL, 4GL, BOD, BDE, and Report engines.
  5. The standard Application layer has coded actions that must be performed on a certain event. Those actions are plugged into the socket that is meant for this event. Those actions are executed by one of the tools engines when that event occurs. Examples:
    • When a record is updated in a table, also another table must be updated. For example, when the quantity is changed in a sales order line, the inventory allocation also must be updated. In this case the DAL application component has an after.save.object() hook to perform the update for the inventory allocation.
    • When a report is printed, for each detail line also a percentage must be calculated and printed. The report script has a before.field hook to calculate the percentage.
  6. The Tools layer has also specific sockets for the Extension layer. The plug is created by adding an extension in the Extension Modeler. Examples:
    • An overview session must show some additional fields, directly from database or a complex calculation. For example, for business partners the number of open purchase orders should be displayed. This field, with the code to calculate the value, must be added in the session extension.
    • An Infor Reporting report requires to print sub-details. Those sub-details must be added to the XML data source by adding additional rows. You can do this in the report extension with the write.row() hook.
  7. Next to the specific sockets for the extensions, extensions can also act as an adapter. In this case the standard plug is adapted. There is a standard plug that does specific actions when a record is saved. For example an update on the inventory allocation when a sales order line is inserted. The extension plug can do additional actions, for example inserting data in an own table. Adapters cannot bypass the standard behavior.
  8. The extension can remove a standard plug and connects its own plug to the socket. For example, some form commands of a session can be removed, and other form commands can be added.
  9. Another concept of extensibility is that the standard application itself has sockets. Functionality that had to be customized often in the past, can be influenced by plugging in some own pieces of code.
    Note: The concept of application sockets is not widely implemented in LN 10.5. The Document Output Management example, mentioned on the second bullet, is available.

    In LN 10.6 and later and in LN Cloud this concept is used in the Infor LN application. It can be implemented as process extensions.

    See the Infor LN Public Interfaces and Process Extensions Reference Guide.

    For more information about custom plug-ins in Document Output Management, see Infor LN Document Output Management User Guide.

    Examples of application sockets that can be implemented or are implemented:

    • To change the compose invoices algorithm:

      Items that have a different value in a specific customer defined field, must not be combined in one invoice. In the application extension, you can check whether the CDF has a different value. If so, then inform the standard application that this line cannot be added to the invoice. It must be on a separate one.

    • LN’s Document Output Management is flexible. If you require an output channel that is not supported in the standard application, then add your own output channel in the application extension.