I'm attempting to import a wsdl into Azure APIM and getting an error that the wsdl file can't be parsed, and therefore I don't have a complete list of operations in APIM. If I attempt to import via app service (SOAP APIs) I don't receive an error but the list provided is also not a complete list of operations. When I upload the file I do receive a complete list of operations (without error) but then I am not provided any input parameters when attempting to test in the testing tab of APIM in the portal. Importing the wsdl via a file appears to be most successful option of the 3 but still returns an error. I've imported wsdl before and I don't recall running into this issue. Any idea why this is happening?
FYI... I can use the SOAPUI to test the SOAP api directly without using APIM.
When importing an API, you might come across some restrictions or identify issues that need to be rectified before you can successfully perform the import.
For WSDL below are the points we need :
WSDL files are used to create SOAP pass-through and SOAP-to-REST APIs.
SOAP bindings -Only SOAP bindings of style ”document” and “literal” encoding are supported. There is no support for “rpc” style or SOAP-Encoding.
WSDL:Import - This attribute isn't supported. Customers should merge the imports into one document.
Messages with multiple parts - These types of messages aren't supported.
WCF wsHttpBinding - SOAP services created with Windows Communication Foundation should use basicHttpBinding - wsHttpBinding isn't supported.
MTOM - Services using MTOM may work. Official support isn't offered at this time.
Recursion - Types that are defined recursively (for example, refer to an array of themselves) are not supported by APIM.
Multiple Namespaces - Multiple namespaces can be used in a schema, but only the target namespace can be used to define message parts. Namespaces other than the target, which are used to define other input or output elements, are not preserved. Although such a WSDL document can be imported, on export all message parts will have the target namespace of the WSDL.
For more info, follow this :
https://learn.microsoft.com/en-us/azure/api-management/api-management-api-import-restrictions
Related
I am struggling to create and configure an Azure Enterprise Application.
I have been trying to accomplish this task via PowerShell. I attempted to create an enterprise application by making use of the tags an application registration can have by following this github post, which essentially boils down to adding this tag to the service principal:
$tags = #("WindowsAzureActiveDirectoryIntegratedApp")
From there, I seem to be having problems with adding an identifier uri to the application. Here is the error:
Values of identifierUris property must use a verified domain of the organization or its subdomain
This error does occur to me whether I try this using PowerShell or Terraform.
I think it might be possible to resolve this error by adding the url as a custom domain, but the weird thing is that this url is used by the enterprise application that is setup manually, so I'm a little confused by this error and think the problem might be more than just adding the url as a custom domain.
I would like to note that at this point if I remove the identifierUris the application registration and service principal are both created, but if I were to go to SAML section of the service principal, there does not seem to be a way to manually upload a SAML metadata file (via PowerShell only - it does work in Terraform, interestingly enough).
This brings me to the other issue that I face for configuration: SSO configuration, specifically via SAML. I would like to programmatically upload a SAML metadata file and then modify some of the fields in the SAML section of the service principal from the result of that upload. However, I have been unable to find a way to do this or find an equivalent workaround.
EDIT: Turns out you can upload a token certificate to the service principal via Terraform - for more info on the command see here. You will need to transform your data into an accepted value format (I would recommend .pem if you are coming from a .xml file). I am not 100% sure if this command works yet, as I am left with this message under the SAML Certificates section:
**Token signing certificate**
A certificate has been successfully created. Please reload the page to make it active.
And reload doesn't seem to be working yet...
Issues still left to address:
Identifier uri (previously mentioned)
How to edit the Attributes & Claims fields
EDIT 2:
So I was able to uncover this resource, which offers a step by step guide for automating away SAML-based single sign-on via MS Graph.
Still testing it - and there are some parts that can only be done on Windows (creating a custom certificate) - but this seems very helpful.
Based on my early testing, the only problem I have found with this method so far tis that might not edit the Attributes and Claims section of SAML SSO. However, I believe by creating your own application template this method solves the identifier issue I was running into.
So, the MsGraph tutorial largely covers most of what I needed for my usecase. A few things of difference that I would note:
I used a template application that suited my needs better*.
Attributes and claims are fixed by following the tutorials points on creating and assigning a claims mapping policy. You will not be able to see this through the GUI. Additionally, getting the updated service principal also does not display this configuration**.
If you have difficulty updating your logoutUrl I would see this github post - you can configure it via az rest, PATCH, and this endpoint: "https://graph.microsoft.com/v1.0/applications/$($app_id)".
Tying it all together is a little annoying via PowerShell as it seems that some of the commands take longer to process than others. As a result, I would recommend implementing some sort of retry into your script and even calling Start-Sleep so that future cmdlets recognize resources created by the ones that have already been called.
*Note the process of finding a template that works best for you can be a bit tricky if you do not already have one in mind. I ended up selecting the template that matched the enterprise application I was using when doing this process manually. I am unsure if every enterprise application available has a template that matches it.
**The only way to get a confirmation that a new claims mapping policy worked is to see this message (under the Edit section of Attributes & Claims, which is in the SSO section of the service principal): "This configuration was overwritten by a claims mapping policy created via Graph/PowerShell. Learn More.".
Guidewire Policy Center 10.2 self managed. I'd like to create and quote submission for auto policy line.
Is there a rest api for submission creation exposed via the policy center? Based on the documentation I've an impression it should be there but swagger ui doesn't show related api
I found only soap based web service. Now coming to submission api I see it's very generic, it looks policyPeriodData should be a raw xml that contains all the data about drivers, vehicles etc. How can I get such template in an easy way?
Edit:
Using gosu scratchpad I was able to generate sample xml for policy period
var pp = new gw.webservice.pc.pc1000.gxmodel.policyperiodmodel.PolicyPeriod(pd) print(pp.asUTFString())
it contains drivers data but I don't see any api how to pass vehicles data
We have a custom OData Service. The service url is as below:
https://host:port/sap/opu/odata/sap/ZAPI_TRANSFERPRICE_CONDTYPE_SRV/$metadata
It can return all the price conditions by accessing the following URL:
https://host:port/sap/opu/odata/sap/ZAPI_TRANSFERPRICE_CONDTYPE_SRV/TransferPriceCondition
After the service classes are generated based on the metadata of this service. The getAll method is not generated.
I am not sure if something is required in the OData service.
SAP Cloud SDK Version is 3.7.0.
The getAll() method is disabled explicitly by setting sap:addressable="false" for the entity which is the case in the EDMX file you provided.
generally speaking when using the OData client generator, there will/should be a getAll method if your service does not explicitly forbid it. Can you share the metadata (edmx) file of that service so that we can reproduce the issue? Otherwise it's impossible to guess where the problem comes from.
I am trying to configure Azure API Management to use versioning and have it work with a Swagger / Open API document generated by Swashbuckle.
I have an API with 2 versions - 1.0 and 2.0. I have configured Swashbuckle to generate 2 seperate Swagger documents, one for each version. All good.
The versioning scheme is by path so consumers need to call the correct path (v1.0 or v2.0). Like so: https://someurl/v1.0/some/thing
I have defined both versions in Azure API Management and imported both documents.
The problem is that Azure API Management is adding the path to the base URL and then because the path that is defined in the Swashbuckle generated Open API document I'm ending up with https://someurl/v1.0/v1.0/some/thing in Azure API Management.
Below is a snippet of the generated Swagger / Open API...
And the API version settings in Azure API Management...
And the full URL in Azure API Management...
So, my questions is how can I generate a Swagger document, using Swashbuckle or any other tool in a way that I can support Azure API Management versioning using the path versioning scheme.
Thank you in advance!
Since OpenAPI specification itself does not allow you to define versioning scheme, it is impossible to infer user intention at APIM level. One may want to import API with /v1.0/ in path as a single API, someone else, like in your case, wants to have API + version set. APIM by default does not create/update version sets during API import, so the only way at the moment is to remove /v1.0 prefixes from OpenAPI spec before you import into APIM.
APIMs domain model allows one to control versioning scheme (path prefix, header name/value, query parameter name/value) at the level of API version set, so that you do not need to duplicate /v1.0 on every operation of your API. By nature of this if your API version set is configured to have path prefix of /v1.0 it will be appended to all API paths included into this version set. And that is what produces the doubling.
Looking to create a completely external portal using only HTML5, JS, and CSS to show CRM 2011 data. It does not look like I can use REST or SOAP because they cannot authenticate externally. Does anyone know how I would do this?
Thanks!
To do this, your OrganizationData.svc service would need to be externally accessible, and it would need to function without authentication (or, your authentication would need to happen within your javascript - where the end user would be able to read your source code). Either way is not a wise idea, since all of your data would be visible to the world!
If you are only dealing with internal authenticated users, read up on the oDATA endpoint.
If you want to deal with external and/or unauthenticated users, you'll need to find another way to do this that does all of the data filtering & authorization control you need.
I think we normally achieve this using a intermediary integration service. You could have a service which has access to the Org service through conventional CRM authentication, and which provides a number of methods which can be called anonymously (or by custom security) by client code.
For example, a web page calls the 'int' service's 'getContact' method, passing an email address of the user. The 'int' service validates the user's email address and then retrieves the required data from CRM's org service, using credentials stored in a config file (a CRM user with sufficient permissions to serve the 'int' service's methods). The 'int' service then parses the data and returns it to the client code - which has no knowledge of CRM's existence - perhaps as JSON for usability.