Skip navigation
All Places > PI Developers Club > Blog > Author: pkaiser

PI Developers Club

7 Posts authored by: pkaiser Employee

More Querystring Fun

Posted by pkaiser Employee Apr 30, 2010

Wow, it's been a while since I've found time to blog. I enjoyed meeting many new people at the OSIsoft Users Conference earlier this week, and also seeing lots of old familiar faces. While it's fresh in my mind, I thought I would reiterate the new querystring functionality that was a popular discussion topic at the Users Conference.


If you saw the presentation that I made with Tamara Carbaugh on Wednesday morning, then you already know about all of the new querystring support added to PI WebParts in version 3.0. If not, then you'll be glad to learn that querystrings are an even more powerful mechanism for simple integration in PI WebParts. We've supported querystrings in our TreeView and TimeRange web parts for some time, and in my last blog on the topic I talked about the querystring support in our ad-hoc trend. In PI WebParts 3.0, we've dramatically extended querystring support to the rest of the web parts, and eased some of the restrictions regarding their usage.


In the past, the limited querystring parameter support found in the TreeView and TimeRange parts suffered from a few constraints:

  • The names of applicable querystring parameters were fixed. For example, there was no way to apply a querystring parameter with a simple name such as “Start” to the “Start Time” property of an instance of the RtTimeRange web part. The only querystring parameter that could be applied to the “Start Time” property of RtTimeRange had to be named “RtTimeRange_StartTime.”
  • Querystring parameters were automatically applied to all instances of the applicable web part. In other words, the querystring parameter named “RtTimeRange_StartTime” was applied to all instances of the RtTimeRange web part on the page. There was no opportunity to “opt in” (or “opt out”) on a web part instance-by-instance basis.
  • A single querystring parameter could not be applied to instances of different parts. The querystring parameter named “RtTimeRange_StartTime” was automatically applied to every instance of RtTimeRange on the page, if any, but could not be made to have any effect upon an instance of RtTrend on that same page.

To overcome these constraints, PI WebParts 3.0 extends querystring parameter support to any connectable web part property, and allows the configuring user to specify the name of the querystring parameter to use. This is accomplished through the use of our existing web part connection dialog. Now, when you click our "lightning bolt" button to connect a property to a providing web part, in addition you can connect it to a querystring parameter. You don't have to do both; you can connect a property to another web part without connecting it to a querystring parameter, and you can connect a property to a querystring paramter without connecting it to a providing part. Or you can connect a property to both a providing web part and a querystring parameter. When a web part property is connected to a querystring parameter, but the parameter does not appear in the querystring in the URL, that connection is simply ignored.


So what happens when a web part property is connected to both a querystring parameter, and another web part? And what if that property has a user-specified (i.e. typed-in) default value? Obviously, at the time a web part page is rendered, it is now possible for a web part property value to be provided from multiple sources. For all web parts, a value provided from a connected web part takes precedence. If there is no value from a connected web part, then the value from the querystring paramter is used. If there's no value from a connected web part, and no value from a querystring parameter, then the default value is applied.


As noted in my previous querystring parameter blog, and in the presentation that I gave wih Tamara earlier this week, querystring parameters are a tried-and-true mechanism for simple UI-level integration between PI WebParts and other web-based or web-aware applications. They're widely-used, reliable, and so easy to implement that even a Product Manager could do it. Or an Engineering Group Lead like me, that hasn't written code in a while...

One of the more advanced features of PI WebParts is to allow the creation of a named set of appearance and behavior characteristics for many of our web parts. Called "Advanced Configurations", these named sets of appearance and behavior characteristics can be created for RtMessenger, RtTrend and RtXYPlot, and for the tabular web parts: RtTable, RtValues, and RtTimeSeries. Advanced configurations are created using the administrative web site.


Conditionally changing the foreground and background colors for a dataset column is one of the more powerful options of advanced configurations for tabular web parts. As of version 2.1 of RtWebParts, any number of conditional format specifications can be added to a single dataset column. These specifications are evaluated in order, from top to bottom, and the first specification whose condition is satisfied is applied for the applicable column for each row in the dataset.


There are two subtle points to note about conditional format specifications. First, both operands in the comparison can be column values, even though the second operand is entered with a text box instead of selected from a list of known columns. To compare one column value to another, select the first column in the first operand pull-down, then select the operator, then for the second operand use the "col()" function, with an argument of the column name. The second subtle point follows from the first, and that is that the condition applied to a column does not have to be based on that column's value. In other words, when specifying the condition, none of the operands have to be the column that is being conditionally formatted.


As an example, imagine a dataset with three columns: A, B and C. You can create an Advanced Configuration for the tabular web parts that will change the foreground and background colors of the cells in column A based on comparison of the values of columns B and C in that same row.



As you might have gathered from the change to the name of this blog, the next release of our product will be called "PI WebParts" instead of "RtWebParts." We'll be gradually moving from the old name to the new over the next few months, in the various places where you see our products discussed, such as our web sites, and marketing literature. It's the same product, and of course you will be able to upgrade from RtWebParts v2.2 to PI WebParts v3.0 when it becomes available.

The Selected Data toolpart for RtTrend dictates what traces appear in the trend. It is an ordered list of PI Points, relational dataset columns, and web service parameters, and can also include one connection from another web part. This connection can consume any number of PI Points, passed as a semicolon-delimited list of the format \\piserver\tagname[;\\piserver\anothertagname]*


Often overlooked in the Selected Data toolpart for RtTrend is the "Replace Ad-hoc Traces" checkbox. This property controls the response to the web part connection for the Selected Data property. Checked by default, this causes every new batch of PI Points received via the connection to replace the last batch. In other words, by default PI Points sent via the connection to the Selected Data for RtTrend are substitutive. However, if you uncheck this property, PI Points sent via the connection will be additive -- the existing traces will remain while new traces are added for the new PI Points received via the connection.


For example, when the AliasTagList parameter from RtTreeView is connected to the Selected Data for RtTrend, and ad-hoc traces are not being replaced, each time you click on a Module in RtTreeView, the PI Points to which all of its Aliases refer will be added to the traces in the trend. No single PI Point will appear in the trend more than once, so if a subsequent connection event provides a PI Point that is already being traced, a second trace will not be added to the trend for that PI Point.


The RtXYPlot web part provides similar functionality, allowing additional "Y" tags to be passed in via connection either additively or substitutively. Hopefully calling attention to these features will help you get more value now out of your existing RtWebParts applications.


Querystring Fun

Posted by pkaiser Employee Jan 27, 2009

Querystrings have long offered the opportunity to make configurable web pages, allowing name-value pairs to be tacked on to the end of a page's URL. RFC 1738 (December 1994) describes a "searchpart" as a "query string" that follows a "?" delimiter in an HTTP URL. As a tried-and-true mechanism for passing parameters in URLs, there is of course some support for querystrings in the RtWebParts product.


Many of our customers are familiar with the querystring parameters that can be passed to instances of the RtTimeRange and RtTreeView web parts (if you're not familiar with these, check the product documentation). However, fewer realize that RtWebParts v2.0 introduced a querystring-enabled version of our ad-hoc trend page. Sure, you can invoke an ad-hoc trend from many of our web parts, but there is also a well-known URL to an ad-hoc trend page that can receive start time, end time, and a list of PI tags to trace via the URL. This mechanism is applied by our PI Notifications product to include a link to an applicable trend within a notification email.


The well-known URL for this querystring-enabled ad-hoc trend page is:




Where the <SharePointServer> placeholder represents the name of the SharePoint server where RtWebParts has been installed.


As stated, this page supports three querystring parameters to configure it's appearance:

  • StartTime - UTC seconds or any other time format supported by RtWebParts, such as "*-2h"
  • EndTime - UTC seconds or any other time format supported by RtWebParts, such as "*"
  • Data - A list of one or more PI tags with no delimiter, of the format \\server\tag[\\server\tag]

For example, if your SharePoint server is named "mywebparts", and you want to trace the "sinusoid" and "cdt158" tags from a PI server named "mydata" over the last 12 hours, you would use the following URL:




The StartTime and Data parameters must be provided in the querystring, but if the EndTime is omitted the ad-hoc trend will assume an end time of "*".


As I mentioned, ad-hoc trends are available from the pull-down and right-click menus in several of our web parts. However, the configurability of the ad-hoc trend through its URL provides substantial integration opportunity through basic web mechanisms that need not originate from within web parts or even SharePoint. Of course the RtWebParts product must be installed to a SharePoint server, but once installed this ad-hoc trend is available without ever building a web part page. In short, if you've installed RtWebParts version 2.0 or later, the ability to integrate ad-hoc trending into your web applications using basic querystring parameterization is already available to you. How's that for Value Now? 

Our customers and partners often express interest in creating their own web parts that can connect to RtWebParts. If you’re interested, the first thing that you should know is that RtWebParts are based on the SharePoint web part base class, and not the ASP.NET web part base class. When RtWebParts was first introduced, the ASP.NET web part base class did not yet exist. We have not yet migrated to the newer ASP.NET web part base class, primarily because we’re fond of some of the features that are only available from the SharePoint web part base class, most notably the support for client-side connections. Though it is more difficult to find documentation and examples, you are more likely to successfully create web parts that connect to RtWebParts if you too use the SharePoint web part base class.


Speaking of client-side connections, you might have noticed that in the past RtWebParts supported identical data via two different connection interfaces: IRowProvider, and IParametersOutProvider. One reason for this was to open the possibility to connecting to as many third-party parts as we could. However, though both interfaces provide the same data, there is a slight difference in implementation: our implementation of the IParametersOutProvider interface supports both client- and server-side connections, whereas the IRowProvider implementation supports only server-side connections. There are two important implications of this. First, when you’re creating a web part page and want to connect two RtWebParts together, using the IParametersOutProvider interface to connect them will cause the connection to occur on the client side, whereas using the IRowProvider interface will require server-side connections, meaning the entire page will refresh when data is sent from the provider part to the consumer part. Second, when creating your own custom web parts, if you want to connect them to RtWebParts and support client-side connections in doing so, you must implement the IParametersOutProvider interface for client-side connections, because that’s the only interface that RtWebParts can consume for client-side connections.


Note that the IRowProvider and IParametersOutProvider interfaces are both associated with the original SharePoint web part base class, and not the ASP.NET web part base class. Don’t confuse them with ASP-NET-related web part connection interfaces like IWebPartRow.


One last note on connections – as of RtWebParts version 2.0, our web parts that can serve as providers in a web part connection can also act as filter parts, providing data to consuming web parts using the ASP.NET ITrasnformableFilterValues interface. This is particularly useful in connecting RtWebParts that provide context, such as RtTimeRange, to the Excel Web Access web part, which can be used with our DataLink for Excel Services product to display DataLink spreadsheets in a SharePoint web part page.

Me neither. Actually, we don't translate the product name. But we are translating everything else!


In RtWebParts version 2.2, released last September, we made the last of a series of internationalization changes to the product, to put us in an ideal position for subsequent localization. This localization work is now underway, and soon you'll see language packs released to support RtWebParts in the following eight languages (in addition to the base version in English):

  • Brazilian Portuguese
  • Simplified Chinese
  • Japanese
  • Russian
  • German
  • Spanish
  • Korean
  • French

Look for these language packs on our download site early next year.

Filter Blog

By date: By tag: