The Soap Request from UiPath.WebAPI.Activities is a hit and a miss depending on how the API was designed.
Option 1 If your WSDL from the url does not work in SOAP request, you can try coping the WSDL xml text to a file and use the location of the file. It might still fail when you try with the wsdl file from a file location.
Option 2 Use UiPath Library and used the New Service options to add WSDL from your URL. Services can mostly parse WSDLs where SOAP Request fails. What it does is that it goes to the endpoint your provide and gets all possible operations and their namespaces and imports them to your project / Library. Then within the UiPath library, you can make custom workflows for each of your operations.
Option 3 If Option 1 and Option 2 both don’t work for you, go to the trusty old HTTP Request activity. Why? HTTP request activity can use xml/text as payload. All you have to then do is prebuild an XML using template strings (a file with placeholders). You replace the placeholders after reading the text file and you will end up having a string which can be desearalized (Deserialse XML)
Use a template of the XML structure. Read it as a text file. Use String.Replace to populate the parameter values/Placeholders and repeat it as many times as required. Then use Option 3 as HTTP request can take string as body and can parse the bodyformat as text/xml.
Ingest the text/xml as payload/body text in your HTTP request.
If Option 3 also fails then it is time for PowerShell to do the heavylifting. Similar to Option 3, build up the xml and use $res=Invoke-WebRequest -Method:post -uri $URL -Headers $headers -Body $body -ContentType “text/xml”