The Universal Data Connector (UDC) is actually a framework that allows access to SAP xApp Manufacturing Integration and Intelligence (SAP xMII) services by proprietary server applications that a user may develop. For simplicity these servers will be referred to as Universal Data Servers (UDS).
A UDS can be written in any language. In fact, SAP xMII provides a series of different UDS applications that use the UDC Framework. UDS applications are not confined to Java code. Visual Basic, C++ and other development environments may be used to develop a UDS. A separate toolkit is available for development of Universal Data Servers using any program language that supports the Microsoft Common Object Model (COM).
Conceptually, the UDC communicates with remote UDS servers using TCP/IP sockets. The UDS server receives a request from the UDC, including the appropriate parameters such as mode, tags, date intervals, and so on, and the UDS itself actually handles the I/O to the underlying data source. The UDS then returns status and data to the UDC, which in turn, passes it to the requesting client.
This enables a few important architectural options. First, it allows data access from a platform that does not natively support communications with the underlying data source. For example, it allows a Linux Web server to acquire data from an HMI package running on a Windows 98 PC. Second, it allows "remote-ability" of data access even though the underlying data source may not be capable of remote data access. In other words, you can run the UDS on the same computer as the datasource, and communicate to the SAP xMII Web server through TCP/IP, even if the datasource API does not support IP requests.
Configuring a new server requires that you specify a few pieces of information to tell the UDC subsystem where to locate the UDS server you are interested in connecting to. The pertinent parameters include the name or IP address of the machine where the UDS is running, the TCP port number that the UDS is listening on for connections, and the amount of time that the UDC should wait for a response from the UDS before assuming that communications are not available with the UDS.
There is a 10 second default for this parameter in the event that the QueryTimeout is not set at the server. The QueryTimeout parameter should be optimized for the individual UDS in use and the type of network connection available to the between the UDC and UDS.
All mode requests are sent to the UDS for actual processing, and the UDS will return an error code if the requested mode is not supported. Refer to the documentation for a specific UDS for details on which modes are supported.
|
Name |
Description |
Type |
Usage |
|---|---|---|---|
|
IP |
The name or IP address |
String |
The IP address or machine name where the actual UDS (not necessarily the datasource) service is running. |
|
Port |
Communication Port configured by the UDS |
Integer |
The port that the UDS is listening on. It is recommended that each UDS instance use a different port. The UDS and the UDC instance settings must match. |
|
QueryTimeout |
Query Timeout setting |
Integer |
Time in seconds that SAP xMII will wait for a response from the UDS |
|
Name |
Unique name |
String |
Unique name of the server |
|
Writable |
Enables/Disables Tag Write |
Boolean |
Certain UDS have the ability to write to tags. To turn this feature on, the Writable flag must be set to true. It is suggested that if you wish to do writes to a tag server, that a second server instance be created so that it can be separately granted access privileges. |