we are building ping api for one s4 odata service. From scp application we want to call service endpoint at a repeated interval. How to call s4 service endpoint from cloud-sdk.Generated VDM only gives us the operations endpoints.
Revert for more info.
Thanks
Swastik
You can leverage the HttpClientAccessor to obtain a client for your target system and then perform a simple head request towards the service:
final HttpClient httpClient = HttpClientAccessor.getHttpClient(
DestinationAccessor.getDestination("MyDestination").asHttp());
final HttpResponse response = httpClient.execute(
new HttpHead(BusinessPartnerService.DEFAULT_SERVICE_PATH));
assertThat(response.getStatusLine().getStatusCode()).isEqualTo(HttpStatus.SC_OK);
Here I took the BusinessPartnerService of S/4HANA Cloud as an example.
Is it like a check server availability ping or what do you mean by ping API?
You can use any operation like getAll() or getByKey() to implement a "ping". It very much depends on your knowledge of the service to identify which exact operation to use to make sure the service behaves as you'd expect.
Do you have a certain OData protocol feature in mind that would help to solve your problem, by the way?
You can find more details on the OData client capabilities here. Also, take a look at connectivity options.
If you explain more behind what you call ping we might suggest a bit more ideas. It overall seems like the task is beyond what the SDK should do, but more of an implementation detail of certain service infrastructure.
Related
I am testing Azure TTS service and it is working well on my dev PC.
Now, I am test on a windows server in a secure data center.
However, it may not work because of company firewall system which blocks both inbound/outbound traffic.
So, I need complete API address list to open firewall.
I am using C# and Azure Cognitive Service Nuget package.
I initialize SDK using “SpeechConfig.FromSubscription(key, region)”.
I found that some related address in Azure API help page and Github sample as the followings for southeastasia;
https://southeastasia.api.cognitive.microsoft.com/sts/v1.0/issueToken
https://southeastasia.tts.speech.microsoft.com/cognitiveservices/v1
Could you please let me know whether it is right?
Best regards.
Yea, that is right !
The endpoint is usually of the below type :
https://<REGION_IDENTIFIER>.api.cognitive.microsoft.com/ #for token
https://<REGION IDENTIFIER>.tts.speech.microsoft.com #for other communication
Region Identifier is the region shortened.
The API reference for text to speech is detailed here.
Alternatively, if you are looking to allow all Azure cloud traffic. The below would be complete list. This would be the recommended approach (The below is Public Cloud, For US gov you could refer this).
*.aadcdn.microsoftonline-p.com
*.aka.ms
*.applicationinsights.io
*.azure.com
*.azure.net
*.azurefd.net
*.azure-api.net
*.azuredatalakestore.net
*.azureedge.net
*.loganalytics.io
*.microsoft.com
*.microsoftonline.com
*.microsoftonline-p.com
*.msauth.net
*.msftauth.net
*.trafficmanager.net
*.visualstudio.com
*.windows.net
*.windows-int.net
If one application have Azure serviceBus, EventHub in diff Azure Namesapces, web application and also other azure services (eg: cognitive services). can these be accessed with one URL by using Gateway or Load balancer or traffic manager or any other option ?
My problem is - if we have diff namesapces, we need to whitelist every time when there is new Namespaces and it could so too much of a work. so wondering if we can have one common DNS/URL that would make life easier.
Today, Service Bus and Event Hubs don't support any sort of network gateway. This is due to fact that namespace in the connection string used for authorization purpose at the service side.
To add a bit of context to Serkant's statement, support for this scenario is something that is on our roadmap, and hopefully in the near term. Unfortunately, I don't have a date to share currently. The work is being tracked [here] should you wish to keep an eye on it.
I'm having a problem similar to this one. I'm attempting to deploy an API connection via an ARM template, and I'm getting 'ParameterNotDefined' errors when I deploy.
However, instead of creating an API connection to an azure table, I'm connecting to an azure queue.
Instead of getting a specific answer, I'd like guidance on how I can use documentation or other methods to answer this myself: I'm unable to find documentation on the existing APIs that are supported via the "MICROSOFT.WEB/CONNECTIONS" type, as well as the associated 'parameterValues' that each API expects you to supply.
Searching for a solution here is quite difficult because the terms are very overloaded. Here's what I've already tried:
I've tried using the Azure Resource Explorer, but it looks like this browses resources, not available APIs. If I can use it to view APIs, it's not clear how.
I've browsed through samples on the azure quickstart project. I see examples for azure blobs but not queues.
I've read some documentation on this page about creating API connections for logic apps. This appears relevent, and the author mentions making GET requests to "https://management.azure.com/.../" to view API details, but I get authorization header errors when doing this and I'd hope I can get documentation without operating this low on the stack.
I'm going to be creating a lot of API connections with logic apps in the near future and I need a more sophisticated method of discovery then google-searches, stack-overflow, and reuse of code samples. How do I view the entire set of API connections, along with the supported 'parameterValues' that are to be used with each one?
You can use ARMClient to retrieve the needed paremeters.
armclient.exe get https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Web/locations/{region}/managedApis/{Api}?api-version=2016-06-01
For more information https://www.bruttin.com/2017/06/13/deploy-logic-app-with-arm.html
For anyone, checking it now, you can create the Api Connection manually and check the JSON View of it, it contains all the parameters.
I have just read following article
And I really don't get why the AWS API Gateway doesn't support VPCs out of the box and we have to proxy all the requests through a lambda function?
Does anyone have an idea about why is that?
Though I never found any AWS official statement about this matter, I strongly believe that accessing private resources (VPCs, subnets) from an always public entity (as is API Gateway) would require much more effort (testing) regarding the product security.
I don't believe their plan is to keep it like this forever, though. From this same article you linked, they state (my emphasis):
Today, Amazon API Gateway cannot directly integrate with endpoints
that live within a VPC without internet access.
My guess is that "tomorrow" API Gateway access to private resources will exist and, yes, our lives will be easier (and cheaper, btw).
In the end of the day, and given that my assumption is right, I believe it was the right decision: launch a useful (but more limited) version first and learn with it.
EDIT: Since 2017 November, API Gateway integrates with private VPCs. https://aws.amazon.com/pt/about-aws/whats-new/2017/11/amazon-api-gateway-supports-endpoint-integrations-with-private-vpcs/
We have an NServiceBus endpoint that monitors an Azure Service Bus Queue (using Azure as a transport). But not all the clients that send messages to the queue are .NET-based.
Can an NServiceBus endpoint be configured to accept a simple string as input?
I've tried intercepting messages with a class that implements IMutateIncomingMessages, but at this point deserialization from the Azure transport has already failed.
I can inspect the message coming in in a class implementing IMutateIncomingTransportMessages, but I'm not sure if this is the right place.
What is the best way to configure NServiceBus to handle a message being published in the following format (keep in mind this can also come via the Java or Node SDKs, or via an Azure REST endpoint):
var brokered = new BrokeredMessage("This plain string represents the data.");
queueClient.Send(brokered);
Deserialization of this message will fail, because it contains a string, not a byte array as expected by the Azure transport deserializer.
PS: I know it is possible to expose the endpoint as a WCF service, but currently we only have NServiceBus.Host processes that pull from the queue and the WCF solution does not feel like the right solution to me.
As mentioned on twitter earlier, but just including it here for completeness...
If you want to integrate natively, then you have to modify parts of the nsb pipeline to accomodate for your environment.
See https://github.com/yvesgoeleven/NServiceBus.AsbNativeIntegration for an example of such an integration.