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.
|Connection Name||Standard connection name property – must be unique amongst all connections.|
|Description||This is where the administrator can enter notes for the connection.|
|Destination||The HTTP endpoint to which web data requests will be made.|
|SSO Handler||The authentication handler, which will be invoked as required for requests made through this connection.|
|SSO Credentials||Standard credentials property. If static, the specified credentials are used for retrieval for all feeds based on this connection, regardless of the user causing the request to be made. If a variable is used, the normal method is used to resolve credentials to be used.|
|Use External Proxy||Enable this option to direct all requests for this connection via an external proxy. In some environments this may be required if direct access to the destination is not allowed. If enabled the proxy protocol, host/IP, and port must be specified. If the proxy requires authentication, Basic Auth and NTLM are supported.|
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.
|Feed Name||Standard feed name property – must be unique amongst all feeds.|
|Start URI||The URI for the initial request to be made for the frame in which the web content appears on a Page. This property can be either statically defined, or include references to variables. Reasons to use an expression here include: * URI may include information related to the currently logged in user. * The content to be displayed should be affected by context supplied by a Page variable (which in turn might be affected by clicking elsewhere on the Page). In this case, a query string parameter might be expressed in terms of the variable. * The URI may include time or date range information, which is required to be relative to the current time.|
|Rule Name||For advanced use; allows custom, or module-installed HTTP message processing rules to be selected.|
|Logging, and Verbose Logging||The logging level for this web content feed. By default it is set to Production, for which logging will be performed according to the default configuration (normally set to INFO level). If set to Debug, logging relevant to this feed will be performed at DEBUG level. If logging is set to Debug, a further option to enable tracing, called Verbose Logging, is enabled. When verbose logging is enabled, TRACE level messages are logged to edgeweb.trace in the server’s logs directory.|
Errors and Troubleshooting
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.
|Status Code||Possible Reasons|
|NOT FOUND (404)||Start URI is likely incorrect – check for typos, check that variable values are valid.|
|SERVICE UNAVAILABLE (503)||Destination host is unreachable – this could be temporary.|
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.