In most projects, data must be exchanged or synchronized between UBIK® and arbitrary third party systems in the customer's infrastructure, via so-called interfaces. Independent on the actual communication technology (e.g., REST/SOAP web service, or even file-based), which can differ depending on the external system, there are some, well, ubiquitous factors:
- There is a data contract that usually can be modeled in an object-oriented manner (data is structured in objects and properties).
- Data needs to be imported from a third party system, or exported to a third party system, or both.
- Data should only be exported if it was created or changed in UBIK®.
- Data should only be imported if it wasn't already imported and if there is no more recent change in UBIK® that needs to be exported.
Proxies can be used to deal with these factors. A proxy is a UBIK® object acting as a transmission layer between a content object ("Ubikle") and an external system. Primarily, proxies are data containers having knowledge about their last import and export date and time. The proxy technique allows a project engineer to configure a mapping between UBIK® objects and the entities of external systems. For example, if there are "pump" objects both in UBIK® as well as in the customer's ERP system, proxies can be configured to assign the UBIK® properties of a pump object to the equivalent properties from the ERP system. Further, one can configure whether to just receive data from the ERP system or to just send data to the ERP system, or both. For a fully functioning interface, the other required mechanisms are the communication to the third party system (e.g., calling a specific web service), and performing interface runs (i.e., checking for data to synchronize and doing so if necessary). Fortunately, there is an Interface Administration object in UBIK®, that can be used for configuring and triggering interface runs (resulting in an Interface Execution instance).
Proxies, as any other UBIK® object, require a MetaClass describing them. Since proxies have special features, they also have a special MetaClass, called a MetaProxy. A MetaProxy doesn't just have MetaProperties like a usual MetaClass, but it also has ProxyMetaProperties. These ProxyMetaProperties define interface properties with several interesting details:
- The external system's name of the property
- The Ubikle's (content object's) property this ProxyMetaProperty corresponds to
- Whether to enable import for this property
- Whether to enable export for this property
- Whether the property is a primary key for the external system's entity
- etc.
So, in order to configure proxies, one must start with defining a MetaProxy for the entity in question. Then, the MetaProxy can be added to the InterfaceAdministration object. The InterfaceExecution can be customized programmatically to use specific external data readers and writers capable of communicating with the external system, e.g., via web service call. The triggering of the interface using the InterfaceAdministration can be customized programmatically, too, for example when an object is saved.
 | This page is under construction. More detailed instructions will follow. |