Use gsoap to circumvent and modify the parsing of onvif Standard Type Structure

Onvif/gsoap dependency and Problems

1. Onvif is a set of service specifications, Standard Reference
2. Gsoap is a tool chain based on soap communication interfaces.

That is, when we need to access the onvif web service or implement support for the onvif part, and developed based on C/C ++, we need to use gsoap to generate code for calling the interactive interface between them.

Gsoap Generation Code

• Wsdl2h

Convert the service interface description to the soapcpp2 conversion rule to generate an intermediate header file.

We usually choose to implement some service standards in the early stage. Therefore, most of the products generated during this period will be modified to generate the intermediate product. H, instead of all.

• Soapcpp2

This is to convert intermediate definitions into implementation code for use in C/C ++. Basically, the products generated in this process are not specially processed. Because the generation volume is huge, it is not conducive to maintenance and modification. The problem is to find the source or development logic as much as possible.

Onvif Development Problems

The most common problem encountered during onvif development is

1. An error occurred while parsing the call.
2. Soap_dom_element type

The following describes how to effectively handle these two types of problems.

Avoid parsing errors caused by actual service expansion

For the first problem, most of these problems indicate that the structure of the service response is not standardized, resulting in resolution failure. (For example, I encountered xiongmai IPC and failed to test getcapabilities in ODT)

Generally, basic services of service providers can be guaranteed, and problems mainly occur in their extended structure. This is the XSD _ anytype defined in the onvif standard.

Of course, the extension structure is generally an optional field. In this case, we can ignore or not use it (as long as it does not affect our application requirements). I found that we can watch gsoap code generation and final modification practices, the optional fields can be ignored. This avoids parsing errors caused by this situation. A call may lead to application logic decision-making.

Ignore the operation. In this case, I need to find the corresponding structure description in. H of the soapcpp2 intermediate rule. Check carefully that if this field is optional, the comment is ignored. Use the soapcpp2 tool again to generate new code.

Modify XSD _ anytype to the specified resolution Structure

For this, the most common thing is that when we want to handle onvif event notifications, the default generated structure is soap_dom_element. If the type is complex, it will be difficult, it is difficult to need deep traversal. However, the implementation of event is also implemented in accordance with the specifications, and the basic content filled in is of the standard structure type. Therefore, we only need to parse the corresponding structure information to facilitate the development and use of our programs.

For more information, seeOnvif event message parsing.

 

In short, this will make it easier and better for us to use gsoap to assist our development work.Manual serialization using gsoapTo generate a large amount of code using only tools. Because the generated code is normalized and visualized. If you have a glimpse of the essentials, It is very helpful for us to simplify the dependency and reduce the code generation. This is very beneficial for program release and use.