Web content can be presented on Pages through the combination of Web Content Connections and Feeds. The pipeline for web content is shallow, as the data edgeCore is retrieving has already been processed and prepared for presentation; by the time it reaches the Edge server, web content is not normally structured in a way that is suitable for programmatic transform or analysis. The aim here is to bring third-party content and functionality directly into the edgeCore interface.
A web content connection defines how to reach a third-party web application. It also provides options to configure sign-on to occur automatically, and which credentials should be used.
A connection is specified in terms of a primary endpoint. Often, this is enough, as it is the only host that serves HTTP requests for the purposes of the application. More modern applications often require access to multiple servers – for example, for authentication, or static resources. If these can only be reached from edgeCore’s hosts (and not client browsers), then these additional servers will need to be specified in the Allowed Hosts list.
Each entry in the Allowed Hosts list specifies a host or host-matching pattern – a regular expression – which instructs edgeWeb to map URLs in documents returned by the application server to be fetched via the edgeCore server in the same way requests to the primary endpoint for the connection are made. In addition to the host name/pattern, each entry in the list allows filtering based on whether the matched link is HTTP or HTTPS.
A web content feed defines the entry point to a third-party application, or a part of its functionality.
If credentials are being supplied through the use of a variable, it is possible that there are none defined for the administrative user, which will cause the feed preview to fail. In addition, a successful feed preview does not necessarily mean content provided by the feed will be successfully supplied to all users.
Bad credentials will be flagged in a similar way to missing credentials. For static credentials, the associated web content connection will have to be edited and the credentials corrected and saved. For credential variables, use the provisioning configuration screens to locate and correct the relevant credentials.
Various errors may occur when the preview step of the web content feed wizard makes the initial request for the document identified by the Start URI. If direct access to the application is possible, verifying the configuration with your browser by attempting to navigate to the address formed by combining the connection’s Destination and feed’s Start URI is a good place to start troubleshooting.
Also consider that the application in question may require proxied access to more than one server. In this case, additional hosts may need to be specified in the ‘Allowed Hosts’ list.
You might observe problems with content in the page being requested, for example errors when fetching resources, or problems when trying to follow links in the returned document. This indicates a problem with the content transformations defined by the content rule associated with the feed – either a more appropriate rule should be chosen (which may require a more specific adapter to be installed), or custom rules may be required, if the target application is not specifically supported.
An HTTP archive is created every time the Web Content feed wizard is invoked. The HTTP Archive (HAR) Download button is located below the content frame on the Preview step of the wizard. The downloaded file can be loaded in compatible tools like Fiddler, or Charles, allowing you to examine the HTTP messages exchanged between edgeWeb and the proxied application. The messages recorded include those sent and received for the purpose of SSO.