Hi, How does one go about writing a COM Connector?
I understand this is probably not the answer you wanted to get - and there's no real pleasant way to say this -, but writing actual COM Connectors is something OSIsoft does internally - internally only. Coding these is not trivial and is way too complex for us to make this a public things. Plus, these can really easily "destroy" a PI Server, as subsystem threads will make direct calls into the CC code.
If you feel like OSIsoft should develop a specific COM Connector, please do not hesitate to write to Technical Support and formulate it as an enhancement/new product request.
On another hand, if you need suggestions and support on other ways to achieve what you want to do and connect to the system you're thinking of, please go ahead and post it here! Should you have any concern about the confidential nature of a specific discussion, please do not hesitate to write to the vCampus team directly at vCampus@osisoft.com.
Has always been a shame OSI doesn't trust 3rd party developers to create COM connectors, despite OSI documentation implying otherwise:COM Connectors may be in-process or out-of-process COM objects. In-process COM objectsare .dll files, while out-of-process COM objects are .exe files. OSIsoft has developed someCOM Connectors to specific data systems. Others may be available from vendors orintegrators. In general, the decision to build an in-process vs. an out-of-process COM objectis made by the COM Connector developer.
Aren't the subsystems protected by the redirector so snapshot ss & archive ss don't actually call the CC code? So snapshot/archive SS makes requests to the redirector that invokes the correct COM connector (based on the COM program ID configured for the data request tag), if there is not a timely response the redirector returns error or NoData digital state??
RJK SolutionsOthers may be available from vendors orintegrators.
We do trust third parties, I guess the issue here is that it is hard to earn that trust.
You can find a bunch of COM connectors made by third parties that are actually available as interfaces to the PI System (which were not developed directly by OSIsoft but were really compliant to OSIsoft's specifications)
Anyway, I think the point is that we have such a great group of connectors building a new one would mean an overkill most of the time. Why reinvent the wheel? other than for learning purposes?
P.S. I'll try and find more info about this, but my bet is you can connect to almost everything that has been developed already and some things that hasen't yet been built.
It is true the redirector is here to abstract and normalize all interactions between the core subsystems (PIBaseSS, PISnapSS, PIArchSS) and COM Connectors, but it wasn’t designed to fully protect them from a rogue query or a bug in the COM Connector code. All calls to the redirector are synchronous and will therefore tie up a worker thread if the COM Connector hangs.
This is part of the reasons writing a COM Connector isn’t trivial and must go through rigorous testing and validation. A long time ago we had a COM Connector SDK that was available to third parties. This turned out to be a disservice to our customers and from that point, we decided to develop COM Connectors ourselves. Should you have a valid use case and a strong will to develop one of these, I would encourage you to contact Partner@osisoft.com and discuss that with them. We cannot support that on vCampus, however, since this is not a publicly available technology.
No worries Steve, since getting my hands on the OLEDB COM Connector I've thought of a smarter workaround.
Retrieving data ...