HTTP integration concepts 编辑

This section covers basic concepts that are used when creating your HTTP integration and is meant as a reference for improving understanding of how the various components work with each other. In depth training on all these concepts and how they relate to Microapps can be found at the Citrix Training Portal. Be aware that a Citrix login is required to access the Citrix Training Portal.

URLs and URIs

A URL (Universal Resource Location) is a set of schemes that have specific instruction on how to access a resource over the internet.

The URL is basically the address of some service or resource on a network. Every resource that is accessible over HTTP is identified by a URL. These addresses tell our browsers how and where to look for certain resources.

URI (Universal Resource Identifier) sometimes referred to as the Endpoint. It is similar to the URL we saw earlier but has one key piece added. The name of the resource we want to interact with. This string of characters uniquely identifies a particular resource on the network. The URI is the combination of the entire base URL (from protocol to directory) with the addition of the actual resource at the end.

The URLs and URIs of your target application are required when setting up your initial HTTP integration.

For more information, see HTTP integration.

HTTP methods

HTTP methods are verbs that represent the actions a client can invoke against the data or resource on the server. Methods are used to run actions against server resources. You can find information on how HTTP integration uses these methods at API request methods

HTTP methods are involved when setting up your Data Loading and Service actions to load and alter your data for your required microapps integrations.

Constructing HTTP requests and responses

HTTP methods include GET, PUT, POST, DELETE, and so on. HTTP requests tells the server what the client wants to do once connected to the resource. For example, the client can view data or GET, create data or PUT, update data or POST, or DELETE data.

The Path contains the location of the resource requested or the URI. This comprises the server host name and resource location on the server of the specific resource requested, aka the URI.

The protocol defines the language of communication the two systems uses to speak, like HTTP/1.1, for instance.

HTTP requests are composed of the following basic structure:

• Headers

  The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server.

• Body

  The last part of a request is the body, this contains any data to be sent to the server. Not all requests need a body. Only if we are sending data to the server do we need this attribute, like for the POST and PUT methods.

• Response

  After receiving and interpreting a request message, a server responds with an HTTP response message. An HTTP response is the data sent back to the client from the server. It provides to the client a representation of the resource requested.

HTTP requests and responses are involved when setting up your HTTP integration, Data Loading and Service actions, and Webhook listeners to load and alter your data for your required microapps integrations.

Pagination

Pagination methods are configured when setting up your Data loading, Webhook listeners and Service Actions. Each pagination method required is dependant on your target application integration.

To learn more about pagination types as used in HTTP integration, see the pagination section in Data Loading.

Validating APIs

There are various third party platforms (for example, Postman) that enable a good sandbox environment to experiment with your APIs. Plenty of information on using these tools is available via the specific program’s platform and documentation.

HTTP integration and databases

This section describes basic database concepts used when configuring HTTP integration with your target application integration System of Record (SoR).

Basic Database Structure

Database tables are composed of a set of data elements using a model of named vertical columns and horizontal rows. Each intersection of a column and row is know as a cell or entity. A database table has a defined number of columns and can have any number of rows. Each row is a record, and represents one instance of an entity. A specific choice of columns which uniquely identify rows is called the primary key.

Primary key

A primary key is an attribute or column in a table that contains a unique identifier used to uniquely identify each row or record in the table. All primary key values must be globally unique within the column and cannot contain a null value. Primary keys reduce data redundancy and help form relationships between data in primary and foreign tables.

The Primary key is configured when setting up your Data Loading and Service actions.

Foreign key

A Foreign key is a column of a table that points to the primary key of another (foreign) table. Foreign Keys act as a crossreference link between tables and are the basis of how you build relationships in your integration data structures. Foreign keys Must Match the primary key in another table or be a null value.

Data Loading and Service actions.

Relationships

Database relationships are associations between tables that are created using join statements to retrieve data from your target application integration.

• One to One (1:1) A one-to-one table relationship links two tables where the Primary Key in the child table is also a Foreign Key referencing the primary key in the parent table. Essentially this means that the child table shares the primary key of the parent.

• One to Many (1:N) A one-to-many relationship in HTTP integration links two tables where a foreign key in a child tables links to the primary key in the parent table.

  

Relationships are a central concept when editing your tables to create your microapps and are used when creating Custom relationships. You can also read more about establish complex relationships using HTTP integration in Create integration data structures in depth.

Data types

Data types are used when constructing your data structure when configuring Service actions.

• string: An alphanumeric sequence of letters and numbers.
• integer: A whole number — can be positive or negative.
• boolean: True or false value.
• object: Key-value pairs in JSON format.
• array: A list of values.

Data types are defined and configured when setting up your Service actions.

SQL queries

Queries are sent to the Microapps Data Cache to return and display the values in microapps pages. Workspace users see data in their feed and page Data is pulled from the Microapps data cache Using SQL queries.

More information on how to show and monitor SQL in your microapps can be found in Page details.

Additional learning

Additional resource for learning about Microapps and Workspace can be found at the Citrix Training Portal. Be aware that a Citrix login is required to access the Citrix Training Portal.