I am continuing work on an API use case and have found that the Invoke Method activity is generating a xsi and xmlns tages on all the elements in the output. I just want to remove those. I would be grateful for your review and expertise on the the info below. Many thanks.
I am trying to remove those from the output as follows. Using the Google search results (attached) for “UiPath removing unwanted xsi tags and xmlns from XML output”, I encounter the following on step 2.
You are seeing errors because expressions like xDoc.Root.Attributes.Where(Function a a.IsNamespaceDeclaration).Remove() do not return a value they perform an action directly… Try to put this code inside an invoke Code activity VB.NET targeting your XDocument rather than as an Assign activity.
The issue you’re facing with extra xmlns and xsi attributes is usually related to how XDocument handles serialization. That compiler error in the Assign activity is often resolved by using a simple, surgical approach to clean the XML.
Instead of a complex method, perhaps you can try this concise LINQ expression? It removes those unwanted attributes very effectively.
Assuming your deserialized XML is stored in a variable named xmlDoc (Type: System.Xml.Linq.XDocument), use a single Assign activity:
Thanks very much all. A redacted form form of the data along with a copy of the XAML is attached. You can see where the additional tags come in. I also attached the spreadsheet that serves as the source of data for the table. I think that will help detail how the output got to looking like it does.
we are using the Invoke method, as the called method is a void method (sub, subroutine) which will not return a value and therefore we cannot use within an assign activity (the error which you faced above: Expression does not prodice a value …)
However, it also seems a bit like an XY problem to us. When working with XML, we are dealing with structures. When we use XML structures, we define them beforehand. And then we decide on the approach for converting Excel into the previously defined XML structure.
The Y seems to us to be that, since some option was chosen beforehand to convert Excel data to XML, the focus of the task was then on cleaning up.
Big thanks @ppr. I will work that. Your point is well taken. Yes, I am cleaning up after the fact if you will. My sample flow built a table by reading a very raw spreadsheet. Those tags were baked into the outcome once I did what I did. The API use case of course will have me building that table as a part of a flow. Still, as I think about it, your solve here will likely be part of the solution. Most appreciated.
