An alternative approach that has been working extremely well for me of late is to use the web service interface instead. I write all of my C# utilities to call into the web services in Integrity instead of attempting to hit the API directly. This gives the advantage of being able to distribute the utilities to any server or client. I also tend to create a C# abstraction in between as well, where I further augment processing by exposing my own web service. For example, I have scheduled generation of charts happening at night. Using a trigger takes too long and ties up the scheduler for other tasks. So instead, I created a C# abstraction web service that handles all of the Integrity calls and chart generation, and then have a client utility call into the abstraction web service to tell it which items to process. This offloads processing from the Integrity server, doesn't require the scheduler, and provides an abstraction (in this case) where I can remove and replace the charting code with something else and not affect the clients.
All around this technique has been invaluable. It does have the disadvantage of having more network hops, and the disadvantage of the Integrity web service not always providing the same information that's available through other APIs/CLI.
I can see cases where a .NET/C# direct API would be useful as well, but short term I find the web service approach to be available and relatively easy to use, with added advantages of workload distribution.
Thanks for posting this idea. However, PTC do not have any plans to work on this enhancement - based on the feedback received, analysis & discussions internally.
