I'm attempting to integrate a SOAP web service into my C# project via "Add Service Reference," as I have done successfully at least once before. The address works normally in SoapUI, and even entering the address in a browser brings up the WSDL file as expected. But when I enter the address in the Add Service Reference dialog, it results in an error.
The document at the url [redacted].com/uesas/WebService/Onboard-2_0.cfc?wsdl was not
recognized as a known document type. The error message from each known type may help you fix the problem:
Report from 'XML Schema' is 'The root element of a W3C XML Schema should be and its namespace should be 'http://www.w3.org/2001/XMLSchema'.'.
Report from 'DISCO Document' is 'Discovery document at the URL [redacted].com/uesas/WebService/Onboard-2_0.cfc?wsdl could
not be found.'.
The document format is not recognized.
Report from 'WSDL Document' is 'There is an error in XML document (2, 129).'.
The string 'http ://webservice.uesas._[redacted].webroot' is not a valid Uri value.
Metadata contains a reference that cannot be resolved: '[redacted].com/uesas/WebService/Onboard-2_0.cfc?wsdl'.
The content type text/html of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 1024 bytes of the response were:
... followed by the first several lines of what is clearly HTML code, instead of WSDL code. So evidently, VS doesn't even SEE the WSDL file, even though SoapUI and any standard browser confirm it's there. Does anyone have any thoughts why this would be?
Add ?WSDL after the endpoint address like: http://localhost:8088/mock_service?WSDL
Related
I have an XML sitemap located at https://store.usbswiper.com/sitemap_index.xml, which as you can see loads just fine.
However, Google Search Console is telling me it can't fetch the sitemap.
When I use this validator it's giving me a successful validation.
I have checked the robots.txt, and it's not blocking anything. It specifices the sitemap URL correctly as well.
Any info on why Google Search Console is giving me this "couldn't fetch" message would be greatly appreciated.
EDIT: When I first ran that validator it gave me this error:
Incorrect http header content-type: "" (expected: "application/xml")
I added a robots.txt and then when I ran it and posted this thread it was validating successfully. I just now tried again and it's failing again with the same message. I don't understand why it's working sometimes and sometimes not. The Search Console hasn't successfully loaded at all no matter what the validator is doing.
Add the full link in console;
for example, add https://example.net/sitemap.xml
rather than just sitemap.xml.
I am attempting to create a custom connector for the Clio API (https://app.clio.com/api/v4/documentation). I was able to successfully authenticate and access the API in Postman, testing out quite a few different types of requests with good results.
Then I exported the collection to a Postman file and imported it into a new custom connector in my MS Flow account as instructed at https://learn.microsoft.com/en-us/connectors/custom-connectors/define-postman-collection. As part of that process, I entered the following settings:
Scheme: HTTPS
host: app.clio.com
Base URL: /
Within the custom connector requests, all the definitions looked acceptable, except that instead of having the fully qualified request URL, they did not include https://app.clio.com.
For example, one request should use the following address:
https://app.clio.com/api/v4/contacts.json
The field in MS Flow, where URL should be entered, is grayed out and only includes /api/v4/contacts.json and looks like this:
The grayed out field cannot be typed in. Instead, I have clicked "Import from sample," which leads to a window where I can type in the fully qualified URL. After I do that and click the "import" button, the window still lists the partial URL as shown above.
At first I thought that was intentional, since I had entered the host elsewhere for the connector, and I thought that Flow would put them together to send the request to the right URL. But it did not: when I tested the operation, I got a 404 error:
{
"error": "{\r\n \"code\": 404,\r\n \"message\": \"Unable to match incoming request to an operation.\",\r\n \"source\": \"msmanaged-na.azure-apim.net\",\r\n \"path\": \"\",\r\n \"clientRequestId\": \"500779d5-356d-4c79-bf96-caf2-f5bc2919\"\r\n}"
}
When I looked at the request, this is the URL:
https://msmanaged-na.azure-apim.net/apim/clio2.5fb03ce8462066f352.5fdeb6bc35b813689d/92053762-68ce-4c1d-9085-0785-0fd98c3b/api/v4/contacts.json?type=Person
So obviously Flow is not using the correct request URL, and I cannot figure out how to enter the fully qualified request URL. Can anybody tell me what I am doing wrong?
I found another comment where someone else is having the same problem: https://stackoverflow.com/a/48813209/7191369 so I'm not the only one. Thanks in advance for your help.
Edit:
After some additional searching, the address in the request (with https://msmanaged-na.azure-apim.net) is the required redirect URL for the proxy per this post: https://powerapps.microsoft.com/en-us/blog/custom-api-with-authentication/, and is used when processing OAuth. But the crappy part of this is that I can't see the request URL so I can't troubleshoot. Is there any way to see what request the proxy server is sending out to the Clio API?
It's been a while since this question was posted, but let me give you a suggestion to include the /api/v4 part of the URL inside the Base URL property of the Flow. This way all your endpoints will use the specified version and you will not have to define them one by one in each request.
Except if you intentionally want to use different versions across the requests :) Anyways, I'm glad that you've been able to resolve the issue.
With a Visual Studio 2010 Web Test the Url property can be data bound to a list of URLs from a CSV file but it seems the Expected Response URL can't be data bound. The Expected Response URL just takes a string value. Am I missing something?
In this situation how could you test to see the URL of the page requested is actually the URL of the page you end up on and not a redirection to some other page?
The Expected Response Url can actually be data-bound -- you just have to enter the appropriate context parameter name by hand (don't forget the curly-braces).
The fact that you don't get the helpful drop-down arrow that opens the data-binding panel/list is a UI oversight/bug.
I'll report that on Connect but [dig] don't hold your breath that it'll get fixed [/dig].
I am currently working on an application that allows reverse geocoding using silverlight + bing maps. The thing is that I want to add a reference to the reverse geocoding service provided in msdn ( http://msdn.microsoft.com/en-us/library/cc879136.aspx) i.e. http:// dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc?wsdl, but when I try to get a reference in vs2010, I get the following error:
The document at the url http:// dev.virtualearth.net/webservices/v1/metadata/geocodeservice/geocodeservice.wsdl was not recognized as a known document type.
The error message from each known type may help you fix the problem:
Report from 'XML Schema' is ''', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.'.
Report from 'DISCO Document' is ''', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.'.
Report from 'WSDL Document' is 'There is an error in XML document (1, 1).'.
'', hexadecimal value 0x1F, is an invalid character. Line 1, position 1.
Metadata contains a reference that cannot be resolved: 'http://dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc?wsdl'.
Content Type application/soap+xml; charset=utf-8 was not supported by service http: //dev.virtualearth.net/webservices/v1/geocodeservice/geocodeservice.svc?wsdl. The client and service bindings may be mismatched.
The remote server returned an error: (415) Unsupported Media Type.
If the service is defined in the current solution, try building the solution and adding the service reference again.
It is good to mention that I can access the service URL from the browser (with a no style information warning). I am aware that there are other reverse geolocoding services out there, but I am somewhat forced by certain circumstances to use only Microsoft-related components/services. Please help :)
I've just tried the same thing and it seems to work fine for me. I saw an article on the MSDN newsgroups that suggest there may have been a problem at some stage with the references (see a post on Bing Map Route Calculation Service) although it mentions that it was the staging URL's that were causing a problem, not those that you're using (as in the article currently). Other than that, are you using the current RC of VS2010? (on the off chance that there were issues in an earlier version)
Might be worth trying again; I've whipped up a stub application at http://code.google.com/p/bingmapssilverlightapp/downloads/list if it's any use.
No matter what i attempt i keep getting the following exception being thrown by MSCRM 4.0
Invalid format of input XML for request SetStateITG_glcode: required field 'EntityId' is missing
here is the captured SoapEnvelope from WireShark going to MSCRM where you can see that there is in fact a EntityId element.
<s:Body><ns0:Execute xmlns:ns0="http://schemas.microsoft.com/crm/2007/WebServices" xmlns:ns3="http://microsoft.com/wsdl/types/" xmlns:ns4="http://schemas.microsoft.com/crm/2006/WebServices" xmlns:ns6="http://schemas.microsoft.com/crm/2006/Scheduling" xmlns:ns2="http://schemas.microsoft.com/crm/2006/CoreTypes" xmlns:ns5="http://schemas.microsoft.com/crm/2006/Query" xmlns:ns1="http://schemas.microsoft.com/crm/2007/CoreTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ns0:Request xsi:type="ns0:SetStateITG_glcodeRequest"><ns0:OptionalParameters/><ns0:EntityId>f0754ebf-50d2-de11-93aa-000c29af16b6</ns0:EntityId><ns0:ITG_glcodeState>Active</ns0:ITG_glcodeState><ns0:ITG_glcodeStatus>1</ns0:ITG_glcodeStatus></ns0:Request></ns0:Execute></s:Body></s:Envelope>
here is SOAP body submitted to MSCRM captured again by Wireshark; this message came from a quick console application i wrote to do the update i am trying through my web service client above.
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><Execute xmlns="http://schemas.microsoft.com/crm/2007/WebServices"><Request xsi:type="SetStateITG_glcodeRequest"><OptionalParameters/><EntityId>c2fcef74-19cf-de11-9376-000c29af16b6</EntityId><ITG_glcodeState>Inactive</ITG_glcodeState><ITG_glcodeStatus>-1</ITG_glcodeStatus></Request></Execute></s:Body>
the second message work; and MSCRM does what it is meant to do.
the first one, which other than the namespace prefixes, is the same structure ... as far as i can see.
am i missing something obvious?
what is MSCRM moaning about?
Thanks
so this problem is fixed...
turns out MSCRM didn't like the namespace prefix of ns0
is MSCRM using a custom string parsing based Xml vlaidator or something ridiculous?