Is there a tool in the RTI Connext Launcher that would allow one to publish a topic with data payload defined by the user (other than the shapes demo / IDL extraction / code generation)?
I'm not sure if DDS ping or replay service could be used somehow for this.
The RTI Recording Service has a replay feature that can send data that's been previously recorded and stored in a database. Theoretically, you can manually edit the data in the database and use the replay feature to send it...but I doubt it fits your use case.
What is your use case? If compiling and modifying a simple application is acceptable, then using rtiddsgen and an IDL definition of the data structure for the topic that you want to send, then its quite easy to do that since "rtiddsgen -example <arch>" will generate both a publishing app and a subscribing app along with the build files for your platform. You'll have to make some minor modifications to edit the data that you want to be sent, as well as the name of the topic, but the process can be done in less than a minute...assuming you have the IDL definition of the data structure ready to go, and the data you're trying to send isn't too complex.
But 99% of the code will be generated and ready to go. You would just need to customize what data value needs to be sent.
Otherwise, at this time, we don't have graphically based tool that you can use to do that.
Other options include using a python script, node.js (javascript) with RTI Connector or RTI Prototyper which offers a LUA script. We are also releasing a full Python API for DDS (beta version available now).
Thanks Howard.
The use case is to interface with a DDS based service that lives on a system with many other DDS based apps and services. I am adding "remote control" of some of the service functions. I am considering adding REST API with a couple endpoints or control via a new DDS topic (since all the vendors on the system "speak DDS"). The REST API allows for control without having to build / maintain / make available to all the controller app, so it is a bit more flexible... was wondering if the tool kit allowed for similar flexibility, but I guess not at this time.
Thanks for the info though. The "Python API" might be useful at some point.
Hi Andrew,
Thanks for your reply...but unfortunately, I'm not entirely clear about your system layout. You want to connect to a Service that uses DDS in a system that has other DDS apps.
What is this controller app that you want to connect to the Service? Is this a user-interface that will be ad-hoc and generated/reconfigured at the time it needs to be used? And it's not used all of the time, and will be shutdown and only recreated/started at the next time it needs to be used, minutes of uptime?
Or it is something that's designed/built and then will be in constant use for a longer periods of time, hours/days/weeks? And if something changes, you'll have a process to modify, build and deploy a new version of the controller app?
Also is the DDS Service something that will be changed frequently...specifically the DDS Topics that it uses may be frequently changed new ones added, old ones removed, existing data types redefined?
What does it mean "without having to build/maintain/make available"? What would be built/maintained/made available? Even the RESTful API is one that you have to write code to call (script or otherwise). Using a different API to connect to the Service app means that your Service app now uses 2 different middleware. And it will have to have some way to map the RESTful commands it receives to it's internal workings...which I guess you already have DDS Topics that also map to the same?
And if things change in the Service app (the ways to control the app changes), you'll still have to change the way that the controller app invokes the RESTful API to accommodate the changes if necessary. Using DDS for the same interface, I guess it can be a bit more hassle, since you'd have to recompile the controller app instead of just changing a script or something like that.
What is the programming language/technology being used to develop the Controller app? Is the Controller app going to be executed on a PC/Workstation? On a Android or IOS tablet?
If the controller app is something that's is more permanent (i.e., is pretty much up and running when the system is up and running), but you don't want to hardcode any datatypes/topics in the app, you could look into DDS's builtin topics to discover what topics are being published and then dynamically create datawriters based on the topics that are discovered. The Connext DDS DynamicData API basically allows you to write code to understand and manipulate data structures based on discovered datatypes.
The service resides on a windows PC. It was written in C#. It is under development and currently is controlled via a config file. This will be replaced by some sort of interface (REST API or via a new DDS topic). The DDS topics on the system are stable, not changing often.
The “controller app” does not currently exist. If I add a REST API, then there will be no controller app. The system will be tested using Postman (or similar) to test the REST endpoints. If I control the service via DDS, then I will build a controller app, with a simple user interface, to test the control of the service. This app would then need to be maintained and made available to others. With the REST API I just need to maintain my Postman files for “future testing”.
In the longer term, the control of the service will be done “by other entities in the system”. They will use whichever API I provide to control the service, as needed. As all the “other entities in the system” speak DDS, I am leaning towards control via new DDS topic(s), rather than REST.
Thanks for your questions and thoughts, it is helping me to formulate my solution.
Thanks for explaining a bit more about your system. Since there are plenty of requirements/factors that you have to take into account in your decision, the best I can do is to provide more points to consider.
1) Having the exact same way to control the system app is a good thing...otherwise, you would have 2 code paths in your app that is supposed to do the same thing. And if for some reason using the RestAPI versus the DDS Topics produces different behavior, then you have 2x the code to examine. It's always good to only have a single way to do something (at least in code).
2) RTI actually has something called RTI Web Integation Service (comes as a component of RTI Connext DDS Professional/RTI Connext DDS Secure).
It has a RestFUL front end and fundamentally is a generic, configurable "DDS app". You use XML (or via RestFUL) to configure the Topics, DataWriters/DataReaders that are created by the Web Integration Service. Then, you can use RestFUL to have the Web Integration Service send data or to retrieve the data that it received via DDS.
The downside is that you have to deploy the RTI Web Integration Service (not difficult...it's just an .exe + an XML config file). But the upside is that it's entirely configurable and requires no programming to do basic pub and sub via RestFUL.
Tutorial: https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/manuals/web_integration_service/tutorials.html
Manual: https://community.rti.com/static/documentation/connext-dds/6.0.1/doc/manuals/web_integration_service/index.html