AnsweredAssumed Answered

Basics of the AF SDK

Question asked by andrew_Inwood on Sep 9, 2017
Latest reply on Jun 13, 2018 by Eugene Lee
Branched to a new discussion

Like • Show 0 Likes0
Comment • 6

I am new to the PI AF SDK (previously used the PI SDK, and before that, the API).

I was playing around using some examples, and used this example as a starting point:

https://techsupport.osisoft.com/Documentation/PI-AF-SDK/html/T_OSIsoft_AF_PI_PIPoint.htm

The code I am following is this code:

// Get the PIPoint from the PIServer on the local computer
PISystems myPISystems = new PISystems();
PISystem myPISystem = myPISystems.DefaultPISystem;
PIServer myPIServer = PIServer.FindPIServer(myPISystem, piServerName);
PIPoint myPIPoint = PIPoint.FindPIPoint(myPIServer, piPointName);
// Display information about the PIPoint
Console.WriteLine("Name of the PIPoint = {0}", myPIPoint.Name);
Console.WriteLine("ID of the PIPoint = {0}", myPIPoint.ID);
Console.WriteLine("Type of the PIPoint = {0}", myPIPoint.PointType);
Console.WriteLine("PIPoint Current Value = '{0}'", myPIPoint.CurrentValue());

This code is all very straight-forward, but I have a few questions related to it.

1.) A link to the PIServer can be found and linked without any reference to myPISystems or myPiSystem, by using the alternative overload ( PIServer myPIServer = PIServer.FindPIServer(serverName);). A PIPoint can be found and it's value retrieved with only a reference to a myPIServer. What is the point of first couple of lines of code? Why is the myPISystems and myPISystem required?

2.) I note that PISystem implements IDisposable, but PISystems doesn't. This is not intuitive to me. PIServer also does not require IDisposable. I guess something under the hood sets these requirements, but I figured that a PIServer was similar to a database, so might need to implement IDisposable, but clearly it doesn't.

rdavin

Sep 11, 2017 1:03 PM

Correct Answer

Hi Andrew,

Looking at line 04 of your original post:

PIServer myPIServer = PIServer.FindPIServer(myPISystem, piServerName);

You are attempting to find a PIServer by its name. There are two particular overloads for this:

FindPIServer(PISystem, String)

Remarks: Find the PIServer from the specified name using the credentials of the current user associated with the specified PISystem. This method will NOT require a security check each time it is called if a PISystem is specified.

FindPIServer(String)

Remarks: This method will require a security check each time it is called. Use the FindPIServer(PISystem, String) version to avoid duplicate security checks.

If you are writing an app to interact with your data archive and it has little to do with any AF assets, you may find the second overload more to your liking.

See the reply in context

No one else had this question

Outcomes

John Messinger

Sep 10, 2017 9:29 PM

Hi Andrew,

Some interesting questions!

Looking at that code example, it's not really clear to me why the sample is structured this way. Instantiating the PISystems and PISystem objects is not necessary in order to retrieve a PIPoint value. Looking at the documentation for the PIServer.FindPIServer method overload used on line 4 of the sample, it seems the only benefit of using this is to get a PIServer object that then uses the credentials of the current user associated to the PISystem object. Personally I've never gone down this route for accessing a PIServer and it's associated child objects. In fact, I would probably re-write this as follows:

string piServerName = "BNE-DPI1";
PIServers myPIServers = new PIServers();
PIServer myPIServer = myPIServers[piServerName];
PIPoint myPIPoint = PIPoint.FindPIPoint(myPIServer, "CDT158");  
// Display information about the PIPoint  
Console.WriteLine("Name of the PIPoint = {0}", myPIPoint.Name);  
Console.WriteLine("ID of the PIPoint = {0}", myPIPoint.ID);  
Console.WriteLine("Type of the PIPoint = {0}", myPIPoint.PointType);  
Console.WriteLine("PIPoint Current Value = '{0}'", myPIPoint.CurrentValue());

This is a matter of personal choice in my mind, but this is how I tend to approach something like this.

On your second question, it should be noted that the PISystems class is a global collection of PISystem objects, the key point being it is a collection. It represents the list of known PISystems (AF servers), much like the Known Servers Table in the PI-SDK. As such, it doesn't need to implement IDisposable. As to why PISystem implements IDisposable and PIServer doesn't, I don't really know. Given that this interface is supposed to be used to release unmanaged resources, I'm a little surprised that it is PISystem and not PIServer that implements this. Perhaps one of the AF developers such as David Hearn can answer this particular question.

Regards,

John

2 people found this helpful

Actions

David Hearn @ John Messinger on Sep 11, 2017 1:15 PM

The advantage of using the FindPIServer method where you specify a PISystem object as a parameter is for a slight improved performance. If you already have a PISystem object for a user, this method will avoid resolving the user identity again when looking up the PIServer object for the current user. Each time you call 'new PIServers()' or use the FindPIServer method without specifying a PISystem, the current user identity must be resolved.

For the second question, an earlier release of AF implemented IDisposable on PISystem object to fix an issue with releasing WCF connections to the AF Server. This has been resolved in the newer versions of .NET and therefore is no longer needed but cannot be removed because of backwards compatibility. The only thing it does now is to remove references to managed memory used by the PISystem object, but it can be reused later by re-allocating its memory. For example it would release any cached objects read from the server.

5 people found this helpful

Actions

John Messinger

@ David Hearn on Sep 13, 2017 12:02 AM

Thanks for that explanation David, much appreciated.

Actions

rdavin

Sep 11, 2017 1:03 PM

Hi Andrew,

Looking at line 04 of your original post:

PIServer myPIServer = PIServer.FindPIServer(myPISystem, piServerName);

You are attempting to find a PIServer by its name. There are two particular overloads for this:

FindPIServer(PISystem, String)

FindPIServer(String)

Remarks: This method will require a security check each time it is called. Use the FindPIServer(PISystem, String) version to avoid duplicate security checks.

If you are writing an app to interact with your data archive and it has little to do with any AF assets, you may find the second overload more to your liking.

2 people found this helpful

Actions

gregor.vilkner Jun 12, 2018 8:45 PM

ok. so there's always been 2 folders in my (x86)\PIPC\AF\ directory

.\PublicAssemblies includes OSISOFT.AFSDK.dll version 2.0 targeting .net 3.5 (Details still says 2.9.5.8352) 3.69MB

and

.\PublicAssemblies\4.0 includes OSISOFT.AFSDK.dll version 4.0 targeting .net 4.5 (Details also says 2.9.5.8352) 4.57MB

and the 4.0 dll includes PIPoint and PIServer objects in the Osisoft.AF.PI namespace. So you're correct. No need to reference the pisdk.

Thanks,

Gregor

Actions

6 Replies

John Messinger Sep 10, 2017 9:29 PM
Mark Correct
Correct Answer
Hi Andrew,

Some interesting questions!

Looking at that code example, it's not really clear to me why the sample is structured this way. Instantiating the PISystems and PISystem objects is not necessary in order to retrieve a PIPoint value. Looking at the documentation for the PIServer.FindPIServer method overload used on line 4 of the sample, it seems the only benefit of using this is to get a PIServer object that then uses the credentials of the current user associated to the PISystem object. Personally I've never gone down this route for accessing a PIServer and it's associated child objects. In fact, I would probably re-write this as follows:
```
string piServerName = "BNE-DPI1";
PIServers myPIServers = new PIServers();
PIServer myPIServer = myPIServers[piServerName];
PIPoint myPIPoint = PIPoint.FindPIPoint(myPIServer, "CDT158");  
// Display information about the PIPoint  
Console.WriteLine("Name of the PIPoint = {0}", myPIPoint.Name);  
Console.WriteLine("ID of the PIPoint = {0}", myPIPoint.ID);  
Console.WriteLine("Type of the PIPoint = {0}", myPIPoint.PointType);  
Console.WriteLine("PIPoint Current Value = '{0}'", myPIPoint.CurrentValue());
```
This is a matter of personal choice in my mind, but this is how I tend to approach something like this.

On your second question, it should be noted that the PISystems class is a global collection of PISystem objects, the key point being it is a collection. It represents the list of known PISystems (AF servers), much like the Known Servers Table in the PI-SDK. As such, it doesn't need to implement IDisposable. As to why PISystem implements IDisposable and PIServer doesn't, I don't really know. Given that this interface is supposed to be used to release unmanaged resources, I'm a little surprised that it is PISystem and not PIServer that implements this. Perhaps one of the AF developers such as David Hearn can answer this particular question.

Regards,
John
2 people found this helpful
Like • Show 0 Likes0
Actions
- David Hearn @ John Messinger on Sep 11, 2017 1:15 PM
  Mark Correct
  Correct Answer
  The advantage of using the FindPIServer method where you specify a PISystem object as a parameter is for a slight improved performance. If you already have a PISystem object for a user, this method will avoid resolving the user identity again when looking up the PIServer object for the current user. Each time you call 'new PIServers()' or use the FindPIServer method without specifying a PISystem, the current user identity must be resolved.
  
  For the second question, an earlier release of AF implemented IDisposable on PISystem object to fix an issue with releasing WCF connections to the AF Server. This has been resolved in the newer versions of .NET and therefore is no longer needed but cannot be removed because of backwards compatibility. The only thing it does now is to remove references to managed memory used by the PISystem object, but it can be reused later by re-allocating its memory. For example it would release any cached objects read from the server.
  5 people found this helpful
  Like • Show 1 Like1
  Actions
  - John Messinger @ David Hearn on Sep 13, 2017 12:02 AM
    Mark Correct
    Correct Answer
    Thanks for that explanation David, much appreciated.
    Like • Show 0 Likes0
    Actions
rdavin Sep 11, 2017 1:03 PM
Unmark Correct
Correct Answer
Hi Andrew,

Looking at line 04 of your original post:

PIServer myPIServer = PIServer.FindPIServer(myPISystem, piServerName);

You are attempting to find a PIServer by its name. There are two particular overloads for this:

FindPIServer(PISystem, String)
Remarks: Find the PIServer from the specified name using the credentials of the current user associated with the specified PISystem. This method will NOT require a security check each time it is called if a PISystem is specified.

FindPIServer(String)
Remarks: This method will require a security check each time it is called. Use the FindPIServer(PISystem, String) version to avoid duplicate security checks.

If you are writing an app to interact with your data archive and it has little to do with any AF assets, you may find the second overload more to your liking.
2 people found this helpful
Like • Show 0 Likes0
Actions
gregor.vilkner Jun 12, 2018 8:45 PM
Mark Correct
Correct Answer
ok. so there's always been 2 folders in my (x86)\PIPC\AF\ directory
.\PublicAssemblies includes OSISOFT.AFSDK.dll version 2.0 targeting .net 3.5 (Details still says 2.9.5.8352) 3.69MB
and
.\PublicAssemblies\4.0 includes OSISOFT.AFSDK.dll version 4.0 targeting .net 4.5 (Details also says 2.9.5.8352) 4.57MB

and the 4.0 dll includes PIPoint and PIServer objects in the Osisoft.AF.PI namespace. So you're correct. No need to reference the pisdk.

Thanks,
Gregor
Like • Show 0 Likes0
Actions
- Eugene Lee @ gregor.vilkner on Jun 13, 2018 5:53 AM
  Mark Correct
  Correct Answer
  This is the same for the OSIsoft.AF.Data namespace. Only available in the .NET 4.5 version.
  
  https://techsupport.osisoft.com/Documentation/PI-AF-SDK/html/cc26e52e-b3fc-4b0b-9ff5-0526a8b4c8cc.htm#NET4Only
  Like • Show 0 Likes0
  Actions

Basics of the AF SDK

Outcomes

Related Content

Recommended Content

Incoming Links