The key aspect of the EmpowerID connector model that is important to understand is that the connector functionality is limited to defining the account, group, and organization schema and providing the calling methods for retrieving data and writing of data to/from an external system. It performs limited data transformation or data manipulation and is restricted to enforcing schema restrictions such as data formatting and validation. The connector definition does not generally contain advanced business logic such as provisioning or join logic. You can think of the connector as simply the “plumbing” that transfers data to and from the external system. All other business logic such as inventory processing, provisioning and join logic, group membership assignments, naming conventions, and decisions regarding deleting or disabling accounts are handled through the system's workflows and back-end job processes. Once these various processes occur and the business decisions are made, the data is presented to the connector to be pushed to the external system.
Connector definitions contain the schema definitions for the objects and attributes implemented for the external system and the calling methods for the system they support. Examples of method calls are:
Read Accounts
Read Groups
Create Account
Create Group
Update Account
Update Group Membership
Delete Account
Delete Group
For each of these method calls, the connector definition contains the actual technical implementation for the connection, such as calling a REST API, executing a store procedure, reading a table or view, inserting a record, etc.
One of the benefits of this type of “disconnection” between the business processes and logic and the connector is that common workflows can support any connected system. For example, the create account workflow will take input from the user for any attributes required for an account. The logic to determine what attributes are needed for a particular target system or what mandatory fields need to be completed are contained within the workflow. Once the workflow has completed its accumulation of data and processing any business logic and rules, it simply executes the “Create Account” operation and passes the data. The operation then reads the connector definition for the target resource system and executes the appropriate “Create Account” method defined in the connector. This process separates and isolates the technical requirements for communicating with the target system from the workflow or business process.
Another important aspect of the connector model is that the connector definition is also disconnected from the Resource System and Account Store configuration. The connector definition establishes the available schema, methods, and capabilities of the connector. Still, it does not have the logic that defines what processes will actually be configured to run or the run schedule. For example, the connector will define the calls that are made when the inventory process runs. Still, the account store configuration defines if inventory will even be enabled and the schedule of when the inventory process will run for the system. Simply stated, the connector definition defines what the connector is capable of and how the interaction is implemented. The Resource System and Account Store configurations define what capabilities will be activated and when they will process.
EmpowerID will communicate with a target system via direct calls to the system or source files if they are directly accessible to the EmpowerID server or through the EmpowerID Cloud Gateway if the target system is in a remote or disconnected network. Detailed information about the cloud gateway can be found in the link below.