Blog Series Part 4: Many Connection Types for the External Data Provider, there are
The External Data Provider is THE Swiss Army knife of the Toolset. Sure it connects to your external data, but did you realize all the connection types it supports and the possible properties you can specify with each? During this blog series we’ll cover all the connection types, the properties associated with them and also provide examples for you to reference going forward. This article assumes you have seen a connection file before and understand its format of an opening & closing <CorasWorks> parent element with each connection being stored as a <Data> element within.
This final article in the series will cover two topics actually – the File connection type and the aggregate properties that can be used when “mashing up” data via the External Data Adapter.
A connection type of File, as the name implies, is for when you simply want to connect to a file containing XML data. If the file in question is in a web accessible location, this connection will actually work the same way as if you created an HTTP Post connection to the URL of the file. However, imagine a situation where you have an XML file on a network share. Perhaps you have some legacy or archived data; or it’s a secured application in where you only need periodic data dumps from a secured source you cannot or do not want to tap directly into.
With the File connection type, you can place that XML file on any network resource accessible (from the perspective of the SharePoint server) and pull it in as if it were any other connection type. Update the file in its location; see the results in your SharePoint applications.
The File connection type rivals the HTTP Post in its simplicity. A connection could be as basic as:
|
<Data> <Name>YourConnectionName</Name> <Default>True/False</Default> <ConnectionType>File</ConnectionType> <FileLocation>Path </FileLocation> </Data> |
Your path is then simply a URL, like in an HTTP Post connection, or it can be a UNC network path such as “\\ServerName\SharedFolder\MyXMLFile.xml”. Once you’ve connected to that XML file on your network or out on the web, you have the familiar properties from the other connection types available as well.
They are:
|
Property Name / Element |
Property Use / Function |
|
<Values> |
The Values element simply holds empty child nodes representing each and every parameter that you wish to pass into this connection. Thus, if you plan to pass in a parameter called “Department” into your connection, you would need a self-closing <Department /> element inside your <Values></Values> elements. This is to let the connection know to look for a GET/POST param with the name specified. There’s no limit to the number of params. |
|
<OutputType> |
Default is “text/xml” however “text/html” & ”text/plain” are also supported. |
|
<XslStylesheet> |
Actual XSL to transform the response from your Provider. However, it is recommended to use an attached stylesheet (see next property) as opposed to including your XSL in line here. |
|
<XslStylesheetLocation> |
The URL to the location of an XSL stylesheet (can be .xml, .xsl or .xslt) to be applied for transforming the Provider response. This transform occurs *before* the data is rendered or passed on to another component. |
|
<ErrorRedirect> |
A URL to redirect a user/connection to when the connection called results in an error. |
|
<ReportErrors> |
A true/false flag to indicate whether errors are reported. If set to “true”, and an <ErrorRedirect> is specified, the error message will be attached to the redirect URL as: ErrorRedirectURL?Error=(Error Message) |
|
<RedirectTo> |
The URL to redirect this connection to upon successful completion. This is the ability to take the response from one connection and instantly pass it into another to complete a process or validate a response. If you specify a parameter in the RedirectTo, you can pass the value of the initial connection using a pre-defined variable called %Data%. Ex. http://site.net/subsite/providers/ADO.aspx? ConnectionName=SecondConnection&FirstValue=%Data% |
|
<RDConnection> |
The URL to pass the results of this connection into. This is different than a <RedirectTo> which literally forwards the request on to a new page/connection. With an <RDConnection>, the results of the first connection are passed into a second connection for use in processing said connection, and the results of the second connection are then returned to the first one. This is most useful when needing to send a collection of XML into a second connection since, with the RedirectTo, the entire response of the first connection is passed via query string variable; see the next property for setting the XML elements you wish to post into the second connection. |
|
<RDConnectionPost> |
A property for specifying (via XPath) the XML results from your first connection that you wish to post into a second connection, as well as the parameter names to use when posting them. The <RDConnectionPost> also supports setting a default value to pass for a parameter, should the XPath for the parameter value not exist within the first connection’s result. |
|
<CacheOutput> |
A true/false value indicating whether or not the output from this connection should be cached. If set to “true”, you can use the following three properties to customize the cache label and/or duration. Absent any of the following properties, the default label will be TheConnectionName+”Output”+WebPartID with a duration of 200 mins. |
|
<CacheLabel> |
A text value to specify the cache label; if not specified, the default Web Part ID will be used for this portion of the cache identifier. |
|
<CacheAddUserID> |
A true/false value indicating whether or not to add the ID of the user running the connection to cache label; this is akin to a cache per user mechanism. If set to “true” the User’s ID will be added to the end of the cache label. |
|
<CacheDuration> |
An integer value indicating the cache duration in minutes. |
Finally, I’ll share some properties that can reside outside your individual connections (i.e. outside your <Data> elements) which we call the aggregate properties. A handy capability of the External Data Provider is that you can actually do mashups with it. It doesn’t provide all the feature/functions of the dedicated Mashup Adapter, but for quick & simple vertical mashups, it can often fit the need in short order.
To perform a “mashup” with the EDP, simply create a connection file that (a) has one or more connections set as the default and (b) has one or more connections with the same name. If both these conditions are met, the EDP will make all the connections listed and output their aggregate result as a vertical mashup.
In doing so, we’ve then provided some aggregate properties that you can set for the behavior/handling of the aggregate data returned. Many work just like the similarly named properties within a given connection type, they’re simply applied at the macro level.
These aggregate properties are:
|
Property Name / Element |
Property Use / Function |
|
<AggregateOutputType> |
Default is “text/xml” however “text/html” & ”text/plain” are also supported. |
|
<AggregateXSL> |
Actual XSL to transform the aggregate response from your Provider. However, it is recommended to use an attached stylesheet (see next property) as opposed to including your XSL in line here. |
|
<AggregateXSLLocation> |
The URL to the location of an XSL stylesheet (can be .xml, .xsl or .xslt) to be applied for transforming the aggregate Provider response. This transform occurs *before* the data is rendered or passed on to another component. |
|
<AggregateRedirectTo> |
The URL to redirect this connection to upon successful completion. This is the ability to take the aggregate response from your connections and instantly pass it into another to complete a process or validate a response. If you specify a parameter in the RedirectTo, you can pass the value of the initial connections using a pre-defined variable called %Data%. Ex. http://site.net/subsite/providers/ADO.aspx? ConnectionName=SecondConnection&FirstValue=%Data% |
|
<CacheOutput> |
A true/false value indicating whether or not the aggregate output from this connection should be cached. If set to “true”, you can use the following three properties to customize the cache label and/or duration. Absent any of the following properties, the default label will be TheConnectionName+”Output”+WebPartID with a duration of 200 mins. |
|
<CacheLabel> |
A text value to specify the aggregate cache label; if not specified, the default Web Part ID will be used for this portion of the cache identifier. |
|
<CacheAddUserID> |
A true/false value indicating whether or not to add the ID of the user running the aggregate connections to cache label; this is akin to a cache per user mechanism. If set to “true” the User’s ID will be added to the end of the cache label. |
|
<CacheDuration> |
An integer value indicating the aggregate cache duration in minutes. |
Wrapping up the series, you can download a sample connection file for a File connection, as well as an example of a connection file employing aggregate properties, from the Building Block Exchange section of the CorasWorks Community forum here.
We hope this series has proven useful in opening your eyes to all the possibilities in the EDP. Check back soon for a related post on the EDP’s newest (Toolset v1.4 & later) capability; two-way support for Binary data in your ADO connections.
Buy:Acomplia.Zocor.Lipitor.Prozac.Female Cialis.Nymphomax.Wellbutrin SR.SleepWell.Lasix.Aricept.Benicar.Advair.Seroquel.Buspar.Lipothin.Zetia.Female Pink Viagra.Amoxicillin.Cozaar.Ventolin….