An ERP Connector in Znode is a C# file and the touchpoints refer to the different methods in that class. This is where the business logic should reside for dealing with the ERP Systems, External Systems, and other Data Sources. Using this example you would have three different methods on your ERP connector for each three examples and they would be triggered by different mechanisms. Mechanisms such as an administrator triggering something in the Admin, an Event triggering, or a scheduled task that is automatically run.
This diagram outlines some concepts of the ERP framework. In the middle of the diagram, we have the concept of a touchpoint. This touchpoint is a C# method that gets triggered/invoked by one of the three ways on the left of the diagram
- By a Scheduled task
- By an Event, such as a business-level event on the platform
- By a manual trigger by an admin/user
This touchpoint method can contain any code you want, so it can connect to any ERP or external system with a structure around it. There is a dedicated space in the Admin UI for you to interact with it such as creating specific touchpoints and setting schedules.
Mock ERP Connector
This mock ERP connector is meant for creating a custom one-off. The individual methods inside the ERP connector code are referred to as touchpoints. As a one-time step, the ERP connector has to be configured within Znode. This is found in the Admin > Dev Center > ERP configuration. When adding a new Business System Connector in the package name drop it finds all the C# sharps classes through reflection that extends from the base ERP. Through the standard pattern found in the mock ERP connector, you can see how it extends it. The custom ERP connector has a list of touchpoints which are methods that are available to be enabled by the admin, and each method can be defined by any of the types (asynchronous vs synchronous).
Only one ERP Connector can be active at a time in Znode. This means that in the Znode Admin, you have one ERP connector to manage with one set of touchpoints to configure. The ERP connector shouldn’t be thought of as you create multiple ERP Connectors, one for each system you integrate with. Rather, think of the ERP connector as one class that orchestrates all of the integration activities.
You have a couple of different options for extending this. You can create helpers classes behind the scenes that you could inject into the main connector, and you use those classes to do the heavy lifting/business logic.
In the case that multiple connectors would be present, you would use one ERP connector as a wrapper class. Meaning you would have to organize your code and business logic directly in the connector class. You would treat the connector class as a wrapper around other classes that would contain the business logic of your other system such as a 3rd part connector utility.