Can we talk to the AF SDK from VBA withing Processbook, or do we have to write a .NET addin to access AF?
I can't see it listed under Tools->References.
It is listed but is known as "OSISoft.PI.system", "OSISoft.PI.Modelling" and "OSISoft.PI.UnitsOfMeasure".
Hmm, I can't find those either!
I can see [OSISoft_PB_PINotifications], also [AF 2.x Data Set Processbook Add-in] but not the ones you have mentioned.
Am I missing some AF component that I need to install before these will be listed? Do I need the AF1->AF2 compatability layer?
Ooops, I was on an AF 1.3 machine where the libraries are present & available.
Let me check on AF 2, the DLL's shoud be present in [PIHOME]\pipc\AF\ directory
OK doesn't look like OSI shipped the type libraries required for AF 2 client. OSI...???
That's a bit of a pain, I wonder whether the compatability layer will give me this, maybe in combination with the AF1 client. I am investigating some unrelated stuff at the moment so unless OSI have any advice, I'll try the Compatability Layer route later.
The AF2 SDK is a .NET assembly and we did not intend to support COM interop. Therefore it is required to use a .NET language and you cannot call it from VBA.
From the Release Notes (Known issues):>>COM interface is not supported in this release of AF. Access from COM requires the use of AF 1.3 and the optional Compatibility Feature of the AF 2.0 Client.<<
Will this be brought back in AF 2.1?
Only other way round is to wrap up what would normally be done in VBA in a .Net Processbook add-in. Surely so long as VBA is supported by Processbook/Datalink it makes sense to expose AF2 libraries?
to be honest I hesitate supporting COM technology if .NET is available. However, I see the point of VBA - I'll check with product management what the plans are.
We don't have plans to support COM with AF 2.x. We did it for AF 1.3. But now for integration with ProcessBook we would rather recommend building a custom .Net based add-in. This way user can also leverage our common set of .Net controls. We would need to validate with Steve but I'm pretty sure we have templates and a webminar about building custom .Net based add-in for Processbook.
Yeah the templates are available in the Download Center.
The issue I have with this is clients tend to have lockdown enviroments so it is not that easy to ask them to install a dll addin compared to "just add this VBA code" - not impossible, just not easy.
Just to close the loop in case somebody lands on this thread in the future, the "AF SDK Wrapper for PI ProcessBook" is a PI ProcessBook .NET add-in which exposes parts of AF SDK (a .NET library) to the COM world (e.g. PI ProcessBook's VBA). It is available in the Download Center, under the Extras category. Please have a look into this and don't hesitate to get back to us if you improved it by surfacing additional AF SDK methods...
This AF Wrapper seems to be solution I am looking for, but I have trouble using it.
I have downloaded the AF Wrapper project, built the dll, dumped it in C:\Program Files (x86)\PIPC\Procbook and
registered it using Regasm tool (in C:\Windows\Microsoft.NET\Framework\v2.0.50727) as written in the instruction.
Next thing, when I tried to include the dll in my macro, it did not exist on the list.
Does anyone have any idea about this? I am currently using ProcessBook 22.214.171.124 on Windows 7 64-bit environment.
And the AF version I am working on is of version 2010 R3. Your help would be much appreciated. Thank you.
I tried registering the same dll on another machine running Windows XP and the AF Wrapper did not exist on the reference list.
Does it mean there is something wrong with the dll that I built?
1st please accept our apologies for the late reply.
Did you just copy the library into the Procbook folder or the AFWrapper.pdb and AFWrapper.tlb too?
What happens if you open the WrapperExample.PDI?
Thank you for your reply. It turned out that I did not have to use the AFWrapper to serve my purpose.
I used value tag with reference to Element Relative instead. However, to answer your questions:
I copied the dll and pdb files to ProcessBook folder and did the registration after that.
The tlb file is not found anywhere in the AFWrapper application folder.
And when I opened the WrapperExample it prompted me an error saying that it could not find the specified library.
@Huey Yee: The AFWrapper is written in .NET but with COM Visible property set to true for allowing it to be used by application that "talks" ActiveX/OLE. They are known to type library (*.tlb), you need to create the *.tlb file from the *.dll produced. You can create them by following Microsoft KB here and here for .NET Framework 3.5 and 4.0 respectively. Visual Studio also does it for you when you build your project if you have selected the Register for COM interop in the properties of your project. Make sure you copy the *.tlb file under the .\PIPC\Procbook folder.
Retrieving data ...