11.1. Creating an XML profiles file¶
An XML file can contain several XML profiles.
These XML profiles are defined within the <dds>
element, and in turn, within the <profiles>
XML elements.
The possible topologies for the definition of XML profiles are specified in Rooted vs Standalone profiles definition.
The available profile types are:
Log profiles, and
The following sections will show implementation examples for each of these profiles.
<?xml version="1.0" encoding="UTF-8" ?>
<dds>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles" >
<participant profile_name="participant_profile">
<!-- ... -->
</participant>
<data_writer profile_name="datawriter_profile">
<!-- ... -->
</data_writer>
<data_reader profile_name="datareader_profile">
<!-- ... -->
</data_reader>
<transport_descriptors>
<!-- ... -->
</transport_descriptors>
<log>
<!-- ... -->
</log>
<types>
<!-- ... -->
</types>
</profiles>
</dds>
Note
The Example section shows an XML file with all the possible configurations and profile types. This example is useful as a quick reference to look for a particular property and how to use it. The Fast DDS XSD scheme can be used as a quick reference too.
11.1.1. Loading and applying profiles¶
In case the user defines the Entity
profiles via XML files, it is required to load these
XML files using the load_XML_profiles_file()
public member function before creating any
entity.
It is also possible to load directly the XML information as a string data buffer using the
load_XML_profiles_string()
public member function.
Moreover, create_participant_with_profile()
,
create_publisher_with_profile()
, create_subscriber_with_profile()
,
create_datawriter_with_profile()
, and create_datareader_with_profile()
member functions expect a profile name as an argument.
Fast DDS searches the given profile name over all the loaded XML profiles, applying the profile to the entity
if founded.
if (ReturnCode_t::RETCODE_OK ==
DomainParticipantFactory::get_instance()->load_XML_profiles_file("my_profiles.xml"))
{
DomainParticipant* participant =
DomainParticipantFactory::get_instance()->create_participant_with_profile(
0, "participant_xml_profile");
Topic* topic =
participant->create_topic("TopicName", "DataTypeName", TOPIC_QOS_DEFAULT);
Publisher* publisher = participant->create_publisher_with_profile("publisher_xml_profile");
DataWriter* datawriter = publisher->create_datawriter_with_profile(topic, "datawriter_xml_profile");
Subscriber* subscriber = participant->create_subscriber_with_profile("subscriber_xml_profile");
DataReader* datareader = subscriber->create_datareader_with_profile(topic, "datareader_xml_profile");
}
// Load XML as string data buffer
std::string xml_profile =
"\
<?xml version=\"1.0\" encoding=\"UTF-8\" ?>\
<dds>\
<profiles xmlns=\"http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles\" >\
<publisher profile_name=\"test_publisher_profile\" is_default_profile=\"true\">\
<qos>\
<durability>\
<kind>TRANSIENT_LOCAL</kind>\
</durability>\
</qos>\
</publisher>\
</profiles>\
</dds>\
";
if (ReturnCode_t::RETCODE_OK ==
DomainParticipantFactory::get_instance()->load_XML_profiles_string(xml_profile.c_str(),
xml_profile.length()))
{
// Create DDS entities with profiles
}
Warning
It is worth mentioning that if the same XML profile file is loaded multiple times, the second loading of the file will result in an error together with the consequent error log.
Note
To load dynamic types from XML files see the Loading dynamic types in a Fast DDS application subsection of Dynamic Types profiles.
11.1.2. Rooted vs Standalone profiles definition¶
Fast DDS offers various options for the definition of XML profiles. These options are:
Stand-alone: The element defining the XML profile is the root element of the XML file. Elements
<dds>
,<profiles>
,<types>
, and<log>
can be defined in a stand-alone manner.Rooted: The element defining the XML profile is the child element of another element. For example, the
<participant>
,<data_reader>
,<data_writer>
, and<transport_descriptors>
elements must be defined as child elements of the<profiles>
element.
The following is an example of the definition of the <types>
XML profile using the two previously discussed
approaches.
Stand-alone |
<?xml version="1.0" encoding="UTF-8" ?>
<types>
<type>
<!-- Type definition -->
</type>
<type>
<!-- Type definition -->
<!-- Type definition -->
</type>
</types>
|
Rooted |
<?xml version="1.0" encoding="UTF-8" ?>
<dds>
<types>
<type>
<!-- Type definition -->
</type>
<type>
<!-- Type definition -->
<!-- Type definition -->
</type>
</types>
</dds>
|
11.1.3. Modifying predefined XML profiles¶
Some scenarios may require to modify some of the QoS after loading the XML profiles. For such cases the Types of Entities which act as factories provide methods to get the QoS from the XML profile. This allows the user to read and modify predefined XML profiles before applying them to a new entity.
if (ReturnCode_t::RETCODE_OK ==
DomainParticipantFactory::get_instance()->load_XML_profiles_file("my_profiles.xml"))
{
DomainParticipantQos participant_qos;
DomainParticipantFactory::get_instance()->get_participant_qos_from_profile(
"participant_xml_profile",
participant_qos);
// Name obtained in another section of the code
participant_qos.name() = custom_name;
// Modify number of preallocations (this overrides the one set in the XML profile)
participant_qos.allocation().send_buffers.preallocated_number = 10;
// Create participant using the modified XML Qos
DomainParticipant* participant =
DomainParticipantFactory::get_instance()->create_participant(
0, participant_qos);
}