Can we use the AF Table lookup feature to use the Notifications data ? I would like to retrieve the Notification Acknowledged status tag name(Action tag) using Notification Name. I am using AF 22.214.171.12443 and PI AF Notification 2012
Why do you want to use AF Table Lookup data reference in order to get PI Notifications data? PI Notification has its own SDK called AN SDK in order to have access to the PI Notification data. Have you ever used it?
Thank you for your reply.
I was looking for a simplified way to track the Notification Acknowledgement in AF attributes. I have a template with a AF attribute, whose value I would like to set based on the acknowledgement of a notification.
I thought I could configure a Table connection in AF and access the PIFD database.
The notification state is not stored in AF so you cannot use Table to do a lookup on PIFD. I have seen people use Table with PI OLEDB to get a Notification's state from the history PI Server however I do not think that that solution is what I would call "simple."
Just to clarify, with the current PI Notifications, every notification has attached to it 7 PI tags. The information you're looking for is in those PI tags. Also, the PI OLEDB that Mike is referring to is the Classic PI OLEDB Provider, not to be confused with PI OLEDB Enterprise.
Thank you Steve for clarifying my doubts.
Because Notifications uses PI tags to store information, the approach trough PI OLEDB (Classic) and AF Table Lookup appears like a big detour to me. I rather suggest referring PI tags directly with AF Attributes. You can identify the PI Tags created and used by PI Notifications by their point source: PINotifications-InternalUse
The tag names consist of an identifier and a postfix indicating the use. Notification Name and Target is coded into the Descriptor tag attribute.
Thank you for the reply. You are right. The classic OLE DB approach was wrong. I am now using SQL Client connection and the Notification Tag names to get the details from PI. My problem was to get the Notification Tag name through AF. Since my elements are created programmatically, there was no way for me to know these Tags in advance. I could successfully query the notification database and get the Tag details from there dynamically.
I have no experience implementing that solution. That is what some clever customer came up with. When you say you are using SQL client connection, what exactly are you doing?
Here is what I did,
1. Create a Table in AF Explorer. In the General tab of the table properties click on Import
2. In the import dialog box click on Build to build the connection
3. Select "SQL Server Native Client" as provider
4. In the next tab specify the server and login details. Select PIFD as database
5. Click OK to return to the Import dialog box
6. In the query tab I specified the query "Select * from [PIFD].[dbo].[AFNotification]
This makes the notification data available in a table. I wanted to get the Notification ID for an AF element using this table. To get that I created an attribute in the Element template using string builder as follows,
SELECT id FROM AFTableName WHERE fktargetid = '%ElementID%';
This gives the GUID for Notification.
As all the notification tags follow the GUID_<<String> naming convention. One can get the tag name using this GUID and then read the results all using only AF attributes.
To find out the PI Points for one notification is not so difficult. As Steve mentioned, one PI notification will create 7 PI tags. I believe you should know your PI notifications' names, and if you search all PI Points, you will find that the points made by PI notifications will have the very long names and very long discriptions. In the discriptions, there is a part to show your notification name. Therefore, I believe you could use your notification name to find the points. In addition, the points' name have a part to show which data this point store. I believe you will get the logic for your goal.
Since the tables in PIFD are intentionally not documented, we can change their schema at will without fear of breaking custom code. Though you can certainly explore the schema of tables in the PIFD, be warned that your application will likely break upon the next upgrade of AF.
I just want to add a note that the using the PI points directly is not supported. In the next release of PI Notifications the storage of PI Notification history will not be in PI points, so this solution will not continue to work.
I am interested to hear what problem you are trying to solve that has lead you to this solution.
Is that possible to disclose some information on where we will store the notification information in the next version please? Thank you.
My guess, event frames. Overall EF for when a Notification was running, then child Event Frames for the various states of the Notification.
There are no final decisions made about how to store history, so we can't disclose anything. Ultimately the actual storage location of the information should not be visible to a user and instead we should have better ways to get at the information.
Therefore we are very interested to know what people are trying to do with history currently, so we can find better ways to solve these problems.
Thanks for letting me know your use case Vidya. We will add this as a use case that we should support.
Thank you for the reply. I have AF templates and Notification templates targetting the AF Element Templates. I need to track the notification acknowledgements in AF Attribute for all AF Templates.
All the Elements and notifications for those elements get created programmatically.
Thank you Michael.
I would like to try the PI OLEDB approach. Do you know any documentation on this specific subject that I can refer to ?
Retrieving data ...