GitHub user bossenti edited a discussion: Action Plan OPC-UA Adapter 🚀
During the last time, we had a lot of discussions about weaknesses and potential features of our existing OPC UA adapter. To address those, I'd like to propose an action plan for this adapter that we can try to complete within the current release (`0.93.0`). I browsed through the existing issues and discussions and came up with the following overview. **1) Migrate existing OPC UA adapter and sink to a common module** This is a first refactoring task which allows us later on to share features between the adapter and sink (e.g., authentication) more easily and achieve consistency (as we already did for [influx](https://github.com/apache/streampipes/tree/dev/streampipes-extensions/streampipes-connectors-influx)). This should include: - [x] the actual refactoring to a shared module (https://github.com/apache/streampipes/issues/1648) - [x] Unify the labels for adapter & sink (#1664) - [x] remove `nodeId` & `namespaceIndex` from `SpOocUaConfig` - [ ] https://github.com/apache/streampipes/issues/1693 - [ ] add description to README how adapters can be integrated that build upon the OPC UA adapter **2) Pull & Subscription handling** We support two query options for OPC UA: pull-based and subscription. While we definitely want to keep both, their implementation in a shared OPC UA adapter introduces a lot of complexity and makes the code hard to read and understand. Therefore, we should add some separation here. In addition there is one issue with the subscription mode and our current implementation. Let's say your adapter is connected two `x` nodes, then updates for all nodes can result in up to `x` events. This might not always be the desired behavior. Thus we could introduce a buffering mechanism and allow the user to activate the buffering within the configuration menu. **3) Support OPC UA timestamps** Currently, we don't support the timestamps that are provided by the OPC UA server for every node (server and source timestamp). This can be achieved by providing a configuration field where a user can select which timestamp to use: server, source or StreamPipes. See also: https://github.com/apache/streampipes/discussions/886. To be clarified: Do both timestamps on OPC-UA side always exist? (Potential-Fallback: SP timestamp) - [ ] https://github.com/apache/streampipes/issues/889 **4) Fully support OPC UA types** Our OPC UA adapter can only handle number-based identifier types. This is not compatible with the OPC UA specification (https://reference.opcfoundation.org/Core/Part6/v104/docs/5.2.2). Therefore, we should aspire to get more feature-complete here. - [ ] https://github.com/apache/streampipes/issues/1579 - [ ] https://github.com/apache/streampipes/issues/1693 **5) Remove Requirement of NodeId (& namespace)** If we compare to tools like UaExpert, there is no need to state an initial node id or namespace. We should try to get the same behavior and reduce the configuration effort for users thereby. Furthermore, this should address needs raised here: https://github.com/apache/streampipes/discussions/888 & ttps://github.com/apache/streampipes/discussions/890 This requires a asynchronous browsing of available nodes (see **8)**. **6) Connection Caching** We could cache the connections to an OPC UA server so that they can be shared for multiple adapter instances. See https://github.com/apache/streampipes/discussions/888 **7) Support encrypted connection** As of now, we only support no authentication and authentication via username/password. Encrypted authentication is currently not supported. See https://github.com/apache/streampipes/discussions/1449 **8) Load available nodes on demand** The current adapter tries to load all existing nodes in an OPC UA server recursively which can cause performance problems for larger servers. Therefore, we should introduce partial loading that allows to brows through the existing nodes iteratively. See https://github.com/apache/streampipes/discussions/895 - [x] https://github.com/apache/streampipes/issues/1662 **9) Add integration test** To improve the robustness of our OPC UA implementation, we could introduce an integration test. How could possible options look like? Starting a server in a docker container? **10) Handling null values** This is not specific to OPC UA, but I think it's time to handle null/optional values properly in StreamPipes. References: https://github.com/apache/streampipes/discussions/1596 & https://github.com/apache/streampipes/issues/1485 **11) Celebrate new OPC UA adapter** Once we have implemented the desired improvements, we should promote & celebrate the new OPC UA adapter in form of a detailed blog post. - [ ] https://github.com/apache/streampipes/issues/1551 In the midterm we could also think about having a look at the companion specifications and support some aspects there. This collection is intended as a starting point for further discussion. What do you all think about the different aspects? If not already there, let's create issues to complete the tasks and add them here or start discussions (as individual threads per topic below) about the individual steps. cc: @Praveensteinb @vogler75 @curichan @ohlr @dominikriemer @tenthe GitHub link: https://github.com/apache/streampipes/discussions/1650 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
