I have a program which creates Ace contexts and would like to convert if from PISDK to AFSDK.
This isn't possible with AF SDK as it doesn't access the legacy MDB. Do your ACE contexts exist under %OSI or elsewhere? Generally, %OSI is reserved for internal usage. If the ACE contexts exist elsewhere, you can try using MDB to AF Sync and access AF from the program.
AFSDK does access the "legacy MDB" through the MDB to AF sync. It appears that for some reason it was decided to not map (or at lease not show) %OSI. Let me clarify. The Context, Aliases and properties are defined outside of %OSI but the meta data about the Ace class and it's contexts are within. Specifically, %OSI -> AceClassLibraries -> specificAceClass -> specificAceModule -> Context1, Context2, ..., ContextN where each of these items are a module which should/could be mapped to an AF element, just like other MDB modules are. The only way to create a new context is to use the Ace Manager GUI or do it programmatically (or manually) by adding the right stuff to %OSI. I've got a fairly complicated application which as new objects are added to the application space, creates new contexts, today by making PISDK calls to add modules under %OSI. Would be nice if I could do that with AFSDK.
Thanks for the details. Yes, I understand meta-data for ACE contexts are stored in %OSI. Your use case is less common so I assumed more typical use case (creating Context, Aliases, and Properties programmatically outside of %OSI) in the absence of further information. MDB to AF sync is using a combination of AF SDK and PI SDK. AF SDK was designed to focus on the AF asset hierarchy and therefore, a decision was made to limit MDB access to PI SDK.
In regards to analytics, our development focus currently is on configured analytics via PI Analysis Service. It solves some of the use cases here, as PI Analysis Service will add new analyses automatically as elements/assets are created. It currently does not offer a programmatic interface though. Although not always straightforward, we do encourage customers to leverage AF as most of our future products are geared around this.
"we do encourage customers to leverage AF" ... I'm trying. But it looks like this is one case where there's no choice but to stick with PISDK until you offer an alternative to Ace that works within the context of AF. Speaking of which, I don't think I've seen anything like that on the road map. Any thoughts?
A programmatic interface to PI Analysis Service is something that has been discussed, but Stephen Kwan can provide more insight. Is there a part of PI Analysis Service that cannot satisfy your use cases in ACE? We try to design the analysis functions (PE-like expressions, rollups, event frames) so they satisfy a large majority of the calculations that would have been developed in ACE.
Any programmatic solution to a problem that requires looping or recursion to solve can't be done in AF Analysis (I'm not denigrating AF Analysis - it's great compared to PEs). There will still be some problems that will require either a more robust feature set than AF Analysis currently has or some capability for programmatic extension of an AF Analysis (probably better, we don't need another programming language, do we?).
I also share the same problem, I want an AF ACE
We have many cases where analysis are not sufficient. These cases refer to really complex analysis which must pass through the whole AF Asset Hierarchy and must calculate data at different levels.before getting the finbal results.
We commonly use ACE to schedule dll execution which really do all th AF stuff (we use ACE as a scheduler and nothing more), and we have also developed a little dll execution scheduler, but I would really like to have an AF ACE, as it would
Retrieving data ...