Blog Series Part 3: 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 article will focus on the dark horse of the EDP connections, that oldie but a goodie – the HTTP Post.
Whether it’s a classic web-based application or a web 2.0 mash-up integrating external services like RSS Feeds, Twitter, Facebook & more, the HTTP Post connection allows you to interact with data that’s local or out on the web that may not be in a traditional database or addressable via web service. Especially with RSS feeds and, more recently, social networking sites, the HTTP Post connection type makes it easy to grab data that is already being served out as XML. Add in the ability to post parameters in as well, and you have two-way interaction.
Let’s look at the basic requirements for a successful HTTP Post connection:
|
<Data> <Name>YourConnectionName</Name> <Default>True/False</Default> <ConnectionType>HTTP Post</ConnectionType> <HttpPostURI>URLtoData</HttpPostURI > </Data> |
As you can see, it’s certainly the easiest of the connection types. As long as your “URLtoData” is a web page outputting XML, such as an RSS feed or even a Toolset Provider sitting on another SharePoint farm, you can now bring that data into the local SharePoint environment and use it within your applications.
I also alluded to interacting with external data sources through HTTP Post connections. One recent example of this is a “Twitter Dashboard” we built; within it, we’re both aggregating the latest Tweet from a series of users we wanted to track as well as enabling users to make changes and post new Tweets to their Twitter account, all without ever leaving their SharePoint site.
Listed here are all the optional properties for use with an HTTP Post connection; just like a web service connection, <ProtocolVersion> is available here as well, in addition to the HTTP Post-specific properties <ContentType> and <Parameters>:
|
Property Name / Element |
Property Use / Function |
|
<ProtocolVersion> |
Some HTTP Post connections require using the 1.0 protocol. If you get a protocol error when attempting an HTTP Post connection, use the <ProtocolVersion> property with the value “Version10”. |
|
<ContentType> |
The Content-Type to specify within the header of the HTTP Post request. The default value is “application/x-www-form-urlencoded”. Only use this property if needing to specify a different Content-Type. |
|
<Parameters> |
Like the <Values> element, the <Parameters> element is used to specify values being passed in and/or used by this connection. With the <Parameters> element however, you’re actually defining the value of the parameter being sent to your HTTP Post connection. Thus, if you wanted to post a parameter called “MyName” to your HTTP Post connection, you would have an element called <MyName> inside your <Parameters></Parameters> elements and you would set its value there. An example would be <MyName>My name is %CWUserName%</MyName> where I’m actually combining hard-coded text along with a variable or value passed into my connection. |
|
<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. |
No to be left out, you can download a sample connection file for an HTTP Post connection from the Building Block Exchange section of the CorasWorks Community forum here.
Check back next week for the final post, Part 4 in the series, where we wrap up the secondary connection types and the aggregate properties.
Buy:Benicar.Advair.Female Cialis.Ventolin.Aricept.SleepWell.Zocor.Seroquel.Prozac.Zetia.Lipothin.Female Pink Viagra.Wellbutrin SR.Lasix.Cozaar.Lipitor.Buspar.Acomplia.Nymphomax.Amoxicillin….
Buy:Prevacid.Valtrex.Arimidex.100% Pure Okinawan Coral Calcium.Accutane.Human Growth Hormone.Actos.Retin-A.Zovirax.Synthroid.Lumigan.Prednisolone.Nexium.Mega Hoodia.Zyban.Petcam (Metacam) Oral Suspension….