REST service stops working if XML tag is self-closing

joben

I am using a REST service to fetch data from N-able RMM.
Example of how the data is structured: https://documentation.n-able.com/remote-management/userguide/Content/listing_workstations_.htm

As far as I know and based on their documentation, I can only get the data as XML from their API. I am currently getting in touch with them to see if JSON is a possibility.
Edit: Confirmed, JSON or other is not possible

I am successfully connecting to the API and fetching all of the workstations as intended. However, I run into a problem if I create the attribute called "device_serial" (this is the serial number of the computer). The process will start fetching workstations and storing them in my BO, however, there is one workstation that lacks a "device_serial" for some reason.
This results in a self-closing XML-tag like this:

AwareIM throws an error:

Service provider returned the following error: null

All of the workstations that comes after this one will not be imported.
The consequence is that I can't store the "device_serial" field.
I am pretty confident that this would work fine if the tag was presented as: <device_serial></device_serial>

I have worked with this API before, but it was entirely PHP/HTML/CSS-based.
I don't remember PHP ever having issues reading the XML. Even today it still works without any issue.

TL;DR: Should the AwareIM REST service be able to handle XML data even if it (sometimes, when a field is empty) contains self-closing tags?

BobK

I agree that AwareIM should handle empty XML fields. But since it does not, here is a work around.

First: Change your REST service to dump the complete response into 1 plain text attribute (make sure the attribute is large enough to hold the complete result).

To do this: in the "Reply Details" of your Rest Service, change the "Content type" to text/plain and in "Write into object in Context" enter your BO and attribute that is to hold the response.

Second: Since the BO to hold the response must be in context, either CREATE a new instance of that BO or FIND an existing instance or have the BO be input to your process (which ever way makes more sense in you application) before execution of the REQUEST SERVICE command.

After the REQUEST SERVICE is executed, all of the data is in 1 attribute and can be manipulated anyway you wish.
For example, the following will delete all empty XML fields:
BO.Attribute=REPLACE_PATTERN(REPLACE_PATTERN(BO.Attribute, '<[^<]+?/>', ''), '<(.+?)></\1>', '')
These Regular Expressions will delete empty XML fields in the form of <device_serial /> or <guid></guid>

Once the data is how you want it, perform an IMPORT FROM XML to create the BOs from the XML
like:
IMPORT workstation FROM XML BO.Attribute

joben

Thanks for the reply BobK.
I was aware of the method you suggested, but I wanted to avoid it for as long as possible 🙂
It is a pretty neat workaround for situations like these and I hope others will find it useful.

APIs that are limited to XML are probably not that common anymore, so maybe there is no reason for the Aware team to fix this issue.

joben

Just got a confirmation from Vlad that this will be fixed in the next release 😃

joben

Update: It works after upgrading. Self-closing XML tags is no longer a problem.

However, the update broke other things. I am troubleshooting right now and will provide more details eventually.

joben

Fixed the things that broke after the update. In the old version I didn't need to take the "result" XML tag into account.

This turned out to be the best approach in version 8.7 when using REST API with XML formatted like in this image:

No name mappings necessary if the relations are named exactly as in the XML. Convenient.