CUD interfaces introduction

A summary of available interfaces, their purpose and what can be obtained from them is:

Available CUD Interfaces

*CAS is the CUD Attribute Set; the default attributes available to all users of CUD

Choosing an interface

• If you're doing ad-hoc queries then you should use the CUD UI (User Interface).
• If you have a database which can be addressed remotely using a JDBC driver then you should strongly consider using the SQL push interface.
• If don't have a database, or prefer to download data as text files before loading them into the database, then you should look at the REST interface on the CUD Webservice.
• If you are using a packaged application that is able to use a remote webservice to import data then you should look at the CUD Webservice.
• If you are using a packaged application that is able to query a remote LDAP directory to import data then you should look at the LDAP interface.

The most commonly used interfaces are the CUD UI and REST.  Details of how to apply for access to those are available in the CUD Access page.

The CUD User Interface (CUD UI) is a web application which enables registered users to perform searching and matching

Users can search the CUD database and construct queries to filter the results to those of particular interest.  The search functionality is extremely useful to check an individual's data or to query for a cohort of people who satisfy the search parameters, such as people in your unit with a current University Card.

There is the capability to download your results into a csv, xml or json file.  

There is also an option to include the history and you can view previous values for attributes and the dates on which they were added and updated last. 

Access to the CUD UI is pre-requisite to requesting access to the other interfaces, with all users are encouraged to use the CUD UI Simple Search to familiarise themselves with its features.

Increasingly used by colleges and departments, REpresentational State Transfer (REST) is the preferred method of querying CUD from a server or service.  It allows data to be requested using a simple GET query communicated over HTTPS.  The client is then able to save the data received from CUD to a local file for processing, or store it in memory. Client requirements are that they:

• can make GET requests over HTTPS and process the data returned.

• can use HTTP-Negotiate + Kerberos for authentication using credentials stored in a keytab.

On many Linux/Unix servers curl can be used for this purpose.  For other cases the Cud Client is available which:

• is full self-contained, requiring no additional Kerberos libraries on a system.
• uses Java, with a requirement for Java 7.
• can be invoked unattended in a script.

The end-user can edit their queries, run several different queries and change which data are retrieved without the need of raising a Service Request. 

The data is downloaded to a file, such as xml, csv or json, which can then be processed by the user.

SOAP is currently supported as a means of pushing data to remote webservices.  Requirements are specific to each service.

SOAP would typically be used to send data to, or accept data from, a packaged application which supports SOAP.

CUD can push data to an external LDAP directory, such as Microsoft Active Directory.  Requirements of the directory are that it:

• supports SSL/TLS
• enables CUD to authenticate with a simple bind
• is accessible for connections initiated from CUD server

LDAP would typically be used to provision accounts to the local Active Directory, with the account lifecycle managed by CUD

Commonly utilised by colleges and departments, CUD can push data into a SQL database.  Normally this involves storing data in a table or tables in the remote database which is dedicated to this task.  This data is then processed by local procedures to update other data tables, or referenced as appropriate in queries.

CUD can update the log table either incrementally, or by dropping existing data and repopulating the table(s).  Requirements for the SQL database are that it:

• is addressable remotely on a network port with connections initiated from the CUD servers.
• has a supported Java Database Connection (JDBC) driver
• has username and password for use by CUD

This is far less flexible than the REST query.  The user will need to liaise with IAM to make changes to the data provided, and to inform CUD if changes are made to the target table in the database that may affect the SQL push.

Please note that:

• Microsoft Access and OpenOffice Base are not networked databases and so are not supported
• if CUD updates the data incrementally, expired records may build up, so it would be the user's responsibility to set up processes to identify and handle expired records.

SQL would typically be used to maintain data on a set of people in a database table for use locally.