Skip navigation
All Places > PI Developers Club > Blog > Author: smohr
1 2 Previous Next

PI Developers Club

17 Posts authored by: smohr

Back at the dawn of relational databases for PCs, I managed to issue a query that constituted a Cartesian join.  If you're unfamiliar with the term, I'll wait while you ask a DBA.


Yes, it was that bad.  Fortunately, it was a training class and the server came back after a few minutes.  The point is, I was an unpopular fellow for a while.


I mention that because there are a couple of ways for good people to attract unwelcome attention from their network administrators.  One way is to open your web service to a denial of service attack (intentional or otherwise) in which a client requests ten thousand tags, each with a different PIArchiveManner.  It makes the XML deserializer unhappy.  It makes PI Web Services unresponsive.  If WCF and the web service process it, it makes your networking people very unhappy when that big, big hunk of data goes sliding back through the network.  If you didn't mean to attack the network (like asking for *-4D, * when you meant *-4H on a busy tag), it will also make your client app slow and stupid.


Fortunately, WCF can help.  The various bindings support an attribute called maxReceivedMessageSize.  This is the maximum size, in bytes, of a message that the binding will let through.  A WCF client can use this to guard against a service overloading it, and you can use this in the web.config for PI Web Services to protect the service from a rogue client request. WCF will catch a message that exceeds the given value and not even try to process it.


Samples at Last

Posted by smohr Dec 8, 2010

I've been promising code samples in various venues since, forever, and never got them posted.


This turns out to be a good thing for you, because we've got a couple of new samples.


The samples are for the forthcoming R2 release (coming very soon), and accompany the webinar we offered on November 30th.  If you missed it, you can replay it in the Auditorium.  But we're developers, aren't we?  Less talk, more code!  If you download the following file:


You'll get samples for .NET (WinForms and Silverlight), Java, Powershell (!), and C++.

We've determined that a call to InsertPIData immediately following an IISReset can cause the web service to hang.  A forthcoming release of the PI SDK in the near term fixes the problem.  In the meantime, the work-around is very simple: make a call, any call, to GetPIArchiveData or GetPISummaryData.  The call performs some necessary initialization and subsequent calls to InsertPIData complete successfully.


PI Web Services is now in Beta

Posted by smohr May 5, 2010

The PI Web Services 2010 Beta installation packages for x86 and x64 architectures are available in the Download area under the Pre-Release category.  Be sure you also visit the Library and check out the User's Guide in the Data Access Technologies area as the guide is not included in the beta installation packages.


Perhaps you've heard a rumor...

Posted by smohr Feb 18, 2010

Some comments on the discussion forum say that OSIsoft's Silverlight applications do not use PI Web Services for data access.  We have one forthcoming Silverlight application that could have used PI Web Services but does not.  Why?


The main reason our Silverlight application is not using PI Web Services is that that data feed can be focused precisely on the needs of the classes consuming the data in the Silverlight application.  This is a good result  for the application, but a bad fit for a product, i.e., PI Web Services, that is intended as a general purpose product consumed by all sorts of clients.  Both the custom data layer and PI Web Services share an implementation layer in common; indeed, PI Web Services relies largely on this layer for its implementation.  The end result is that consumers of PI Web Services and the PI Silverlight application will receive the same behavior and data results.  Only the interfaces are different.

If you attended OSIsoft vCampus Live!, you know we've been at work revising the PI WS interface.  What you don't know, unless you tried to access the old CTP recently, is that the new interface is running on the CTP site in place of the old CTP.  First, go to the vCampus Library and look over the documentation for the revised interface.  If you follow the link, look for the vCampus PI Products Kit>Data Access Products path.  The document you want is "PI Web Services -- Revised Interface".


Fired up and ready to test the service?  The WSDL is found at (remember, the host requires the explicit IP address, so the WSDL is static) and will point you to the actual endpoint PITimeSeries.svc.  Go try it out and let us know what you think about the interface!


More on aggregates

Posted by smohr Sep 8, 2009

If we added a new method for the return of aggregates, we would not be stuffing the returned values into a series of time series types as we do presently.  Instead, each path requested would receive a rowset consisting of one row per timestamp, and one column for each aggregate requested.  You'll note that would let you retrieve one set of columns for one path and a different set for another path, e.g., min, max, average, and stddev for sinusoid and range and total for cdep158.  You'd have to make a separate roundtrip for aggregates, but you could fine-tune what you get back.


More on Paths

Posted by smohr Sep 3, 2009

Right now, we have path-context-manner-column as the tuple that locates an item of data.  Let's focus on the first and last (path and column).  To be frank, column grew out of the columns that PI tags return.  Other data sources may not have anything like this.  Would it make more sense to fold "column" into the path syntax for PI points?


Right now, if you provide a list of points (n in number) and a list of columns (m in number), you get n x m results, helpfully labelled "pi:\\server\tag(column)".  If we make the input look like the output, you would no longer have to provide the columns separately and the scheme shrinks to path-context-manner.


The benefits are that you could have a ragged array (e.g., value, max, min, and average for one path and value for another), and future, non-PI sources wouldn't be burdened with a PI-centric concept.  The downside is longer paths.


What do you think?  How would you use the web service?




Associating times with paths

Posted by smohr Aug 28, 2009

This is covered in the CTP documentation, but I want to explore the issue a little here.  The way the WS matches times with paths works like this.  If a time has the name of a path in its datasource property, that time is applied to the path.  If not, the first time in the array is used for a path.


So, if you are doing a trend with three tags, you send the WS three paths and one time range. Got a single value and a trend in your app?  Give use all the paths, then give us the time range of the trend, followed by the single value time instant with the single value path as the value of its datasource property. 


We never, ever, march through the context array trying to match paths and tags one-for-one in order.  This might seem a little counter-intuitive, but it works pretty well and keeps the context array short -- an important consideration for data volume on the wire.  Bear in mind there are a few other wrinkles.  Ranges and instants are just the first context types, and we plan on "casting" contexts.  There are also some provisions in the context realm for intermediate structures to provide for M:M associations between paths and contexts, but that seemed like overkill on the first release.


What do you say?  Can you think of use cases that are hard to satisfy with the rules we have in the CTP?

Since we had the OPC UA webinar yesterday, I think it would be appropriate to make a very brief point about the two prospective products.  OPC UA goes the big standards route.  You have to invest in a lot in terms of the object model and infrastructure, but it offers a lot in return.  If you want industry  standards and a big, robust infrastructure, OPC UA is your path.  PI Web Services, in contrast, was designed from the start to be the way to get data out of PI with a minimum investment of time and effort.  I'm grossly oversimplifying, but the only things the two have in common is web service protocols and PI data.


So -- do you think the path-context-manner-column calling convention meets that design intention?


Java sample

Posted by smohr Aug 25, 2009

Just so our friends in the Java world don't feel left out:


This is a CTP client of the IPIClientServices interface.  It is a little less involved than the WinForms sample.  It uses SWT + Axis, so some assembly of your environment may be required.


Tags, we've got tags

Posted by smohr Aug 25, 2009

Let's say you've jumped in and created a client.  You want to see if it works with the CTP.  What's a good path?


First, the PI server is named jmaytumwin2k8 (hi, John!).  It has the usual suspects -- sinusoid, sinusoidu, cdep158, cdt158, and so forth.  I've also created two tags to test data entry: InsertTest1 and InsertTest2. Since we don't have your user ID in a secure, federated kind of way, I had to open these tags up to the world for read/write access.  So you can get your data in there, but look fast and don't expect any great degree of integrity.


CTP documentation

Posted by smohr Aug 25, 2009

The CTP documentation is up in the vCampus Library, under "vCampus PI Products Kit" and then"Data Access Technologies".  The last entry (currently) is "PI Web Services -- Community Technology Preview". If you click that, you get a PDF which you can save locally.


The documentation contains guidance on using the two interfaces and the structures used to pass parameters to the web service and receive data.  Just remember the path to the WSDL is different.  For that, see


How to access the CTP WS

Posted by smohr Aug 25, 2009

We finally have a hosted CTP of the PI Web Service.  We'll be posting the documentation soon, but there was one change.  Our host uses a static IP address, so we are using static WSDL that has been edited to reflect this.  If you use either URL below, you can create a web service reference or create an InfoPath form that points to the hosted CTP web service.  You can kick the tires for yourself!    (for the InfoPath friendly interface)   (for the more flexible interface)






Okay, NOW it's ready

Posted by smohr Aug 25, 2009

Sample code for a WinForms client can be found here:


The best part?  It targets the live CTP server...running now.


The code isn't glamorous, but it does provide examples for all three methods of the IPIExtendedServices interface.

Filter Blog

By date: By tag: