Routing Service between domain with Different DataTypes

Are you saying that you want to route a topic in one domain to a different topic in a different domain and that the two topics have different datatypes?

Or is it that you just have different topics with different datatypes that you want to route through Routing Service, but the topic name and topic datatype will be the same in the domain from where its published to the domain to where its subscribed.

I assume that you are able to configure Routing Service to do this in the second case (which is pretty much the example configuration distributed with Routing Service).

For the first case, you can't use <auto_route>s which require the same topic and datatype for <input> and <output>, instead, you'll have to use <topic_route> to define a route between domains and between topics with different names and/or different datatypes.  You may need to use an assignment transformation if the names of the members in the input datatype and the output datatypes aren't exactly the same, and you need to map the member of the input Topic to a member of the output Topic.  See the example here, an example configuration file is provided in the workspace in your home directory, C:\Users\<name>\Documents\rti_workspace\6.0.1\examples\routing_service\shapes\topic_bridge_w_transf1.xml.

HOWEVER, the error that you are seeing has nothing to do with the configuration of routes, ""Incompatible offered QoS on DataWriter assocated with topic".  I'm not sure where you are seeing this error message, but assuming that it's being produced by Routing Service, this means that the DataWriter created by Routing Service to publish the data into the <output> domain has a QOS configuration that's incompatible with the applications that subscribe to the data in the <output> domain.

You'll need to use standard techniques to figure out what QOS values are incompatible, I suggest running RTI Admin Console, and then modify the QOS of the DataWriter created by Routing Service to use either the same QOS profile as used to create the DataReaders in the subscribing apps or to just configure the offending QOS policy with compatible values using the <datawriter_qos> tag in the <output> tag of a <topic_route>, see this doc.

How do you mean "reference"?  Do you mean that it uses "#include <another.idl>" syntax?  Or does it just use types that were defined in another file?

Are these IDL files currently used to generate the type support code for your DDS applications?   I assume that your IDL files are passed to rtiddsgen to generate the type support code for the datatypes for use in your DDS applications.

If so, you can use rtiddsgen with the "-convertToXML" command line option to convert an IDL to XML format.  However, you'll need to do it for all of the IDL files that you have if one IDL file includes another IDL file.

Why do you need to convert the datatypes defined in IDL to XML?

I'm not sure what you mean by keeping the dataypes of Domain 1.  If the data types are different in Domain 0 and Domain 1, then when you deal with the data in Domain 0, Routing Service needs to use the data type defined in that domain, and the same for dealing with data in Domain 1.

As explained in my previous response, within Routing Service, you can use an assignment transformation to map members of the datatype defined in Domain 1 to the members of the datatype in Domain 0.

The RoutingService XML configuration file that you provided assumes that the datatypes in the input and output domains are exactly the same, which is why you see your error.

You have to change the Routing Service configuration to use specific data types in the input domain and output domain as well as apply an assignment transformation.  In my previous response, I pointed at an example that you can use and learn from.

No, you don't have to create a transform.  If you look at the XML configuration file, you'll see:

    <plugin_library name="Transformations">
        <!--
        This transformation is implemented in that shared library. It allows
        copying fields from one dynamic data sample to other dynamic data sample
        -->
        <transformation_plugin name="Assign">
            <!--
            By specifing this value, RTI Router will search for
            librtirsassigntransf.so in Unix systems and rtirsassigntransfs.dll in Windows
            systems. The path to search will be the current directory or if
            not there, the RTI Route executable directory, which is where it
            actually is.
            -->
            <dll>rtirsassigntransf</dll>
            <create_function>RTI_RoutingServiceAssignTransformationPlugin_create</create_function>
        </transformation_plugin>
    </plugin_library>

This instances an "rtiassigntransf" which is a DLL/shared library that is distributed with RTI Connext DDS that can be used by Routing Service to map members of one type to another per the other configuration in the file:

                    <transformation plugin_name="Transformations::Assign">
                        <!--
                        We will pass some parameters that the modify method will
                        receive to configure this instance. This transformation expects
                        a set of assignments between a field of the output sample
                        type and a field of the input sample type.

                            In our case, we are getting the fields we need, the
                            coordinates of the input ShapeType sample, and
                            assigning them to the output PointType sample
                            -->
                            <property>
                                <value>
                                    <element>
                                        <name>x_coord</name>
                                        <value>x</value>
                                    </element>
                                    <element>
                                        <name>y_coord</name>
                                        <value>y</value>
                                    </element>
                                </value>
                            </property>
                        </transformation>

So, what project are you working on?  I assume that you have an RTI developer license and the project has support from RTI.  If so, you can ask your support contact (a developer on your project that has been assigned RTI support access) to get additional help directly from RTI's support team.

Your input datatype and your output datatype don't have to be the same datatype.  In the configuration file for Routing Service

                    <input participant="1">
                        <topic_name>Topic1</topic_name>
                        <registered_type_name>Type1</registered_type_name>
                    </input>
                    <output>
                        <!-- Same output topic and type -->
                        <topic_name>Topic2</topic_name>
                        <registered_type_name>Type2</registered_type_name>                       

                        <transformation plugin_name="Transformations::Assign">
                            <property>
                                <value>
                                    <element>
                                        <name>outputfield1</name>
                                        <value>inputfield1</value>
                                    </element>
                                    <element>
                                        <name>outputfield2</name>
                                        <value>inputfield2</value>
                                    </element>                                    ...
                                </value>
                            </property>
                        </transformation>

                    </output>

So if configured correctly, Routing Service will create 2 DomainParticipants, one on domain 0 and one on domain 1.  And it will also create the Topics for Domain 0 and Domain 1.

It's likely to be a configuration problem, if you only see that Routing Service has created topics for domain 1 and not domain 0.  In which case, if you post the configuration, I can help troubleshoot.

So, I see the same topic name and topic type being used for the input (domain 1) and output (domain 0).  Didn't you say that you had a different type for the output?  If so, you need to change your configuration to specify the datatype that you want to use in domain 0.

In addition, Routing Service won't create the datareaders for the input or datawriters for the output if it doesn't know the definition of the datatype.  It usually finds out the definition by discovering an application that uses that datatype in the domain.

So, if you don't have an application that subscribes to a Topic with the datatype in domain 0, then RS won't be able to create a DataWriter until you do.  Similarily, need an application that publishes a Topic with the input datatupe in domain 1 for the RS to create a DataReader.

Just running Admin Console won't trigger RS to create any of the DataReaders/DataWriters that it uses since Admin Console itself has no knowledge of user datatypes on startup.

I thought that your original problem was that you had different data types in the 2 domains and wanted to map members of one datatype to the other by the Routing Service?

In any case, no Routing Service has no idea what the datatype definition is in Domain 0 until you create a DataReader in that domain.  And when that happens, it'll create a DataWriter for the route.

Hi, so to use RTI Connector, you have to define the data type in the XML file.  If you don't, you won't be able to use RTI Connector.

Not with RTI Connector.  DDS must know a data type inorder to receive the data for a topic, deserialize it and provided it to a reader.  Using the standard C/C++ APIs, you can use the builtin discovery Topics to discover the datatypes of user Topics that are being published and then use those dataypes to create a dynamic data reader to subscribe to the data.

I believe that you can also do that with the new Python DDS API that is still in a pre-productization phase but can be found here.

https://community.rti.com/static/documentation/connext-dds/current/api/connext_dds/api_python/