I am new to solace world, Can someone please same any example of subscription to durable topic endpoint in solace API.
A topic endpoint in Solace is a guaranteed messaging object that acts as a holding area for messages for a consumer. It attracts messages published to a topic for which the topic endpoint has a matching topic subscription. The topic subscription for the topic endpoint is specified in the client request to bind a flow to that topic endpoint. Topic Endpoints are equivalent to durable topic subscriptions in JMS.
You can read more about how to create and configure a topic endpoint here
Durability in Solace refers to the lifetime of and endpoint created. You can read more about Endpoint Durability here
Related
I have setup the following:
Azure B2C
Standard user flow
MFA turned on
Twilio account
a US number
a messaging service with web hook
Rest API
Accept POST call from Twilio web hook
I want Azure B2C MFA to send SMS to Twilio and Twilio then trigger a call with the message content to my Rest API.
I have tried this setup and it worked the first two times. However, all subsequent attempts were not successful. I cannot see the received message count in Twilio increase, after MFA SMS is sent from Azure B2C.
Is there any way to find out why this stopped working and is there any settings to configuration that I may have missed configuring?
Any help would be much appreciated.
Right now I am using mosquitto broker for MQTT. But I want MQTT cloud which provides rest API for creating Username and password. I show some of the cloud like, IOT MQTT AWS, and Hivemq but I am not able to find any kind of Rest API document.
Thanks in advance.
in wso2 api manager what is the usage of this wsdl:
RestApiAdmin
https://[apim-host]:[apim-port]/services/RestApiAdmin?wsdl
this is add api but dont show in publisher or store or carbon
what is this usage?
This is the admin service that is used to deploy APIs to the gateway. When you create an API in the API publisher, the API publisher calls this API in the gateway to deploy that API in the gateway.
We recently started using IdentityServer3. There is a requirement to have the call go via a messaging system (proxy) because of network limitations, which is responsible for routing to the RS.
OAuth asks for TLS or an end to end trusted channel.
Now the message brokers are part of a trusted network, but is it a good idea to have the bearer tokens be in clear text at any point midway? Is this something we should be concerned about or trust the messaging system? Or any other recommended approach?
Thanks!
I have a existing application built in ASP.NET. This application has REST APIs. We are wanting to expose these APIs via API connect platform. Now, since our APIs are already authenticated, if we use IBM API connect, then how will end user authenticate to our API and API consumer authenticate via IBM Developer portal?
Lets say our API clientA logs into our developer portal, creates an app and then subscribes to our API. Now when end users try to access our API "VIA ClientA", we need to authenticate the request.
I tried to follow this tutorial http://www.ibm.com/support/knowledgecenter/SSFS6T/com.ibm.apic.toolkit.doc/task_apionprem_redirect_form_.html
But it does NOT get redirected to our external URL.
Please help!
The API gateway (part of API Connect) establishes and enforces authentication between the API end-user/subscriber and your outbound API service running on API Connect. The gateway acts as a service proxy to authenticate potentially many subscribers to a particular API plan (made up of one or several APIs), using API keys that are generated as new subscribers onboard to that plan. The management and enforcement of those API keys is accomplished entirely within API Connect. Nothing is required on your part, except the initial setup parameters for each API.
For that same API, the back-end authentication between API Connect and your existing REST API endpoint is different: it is the same for all end-user subscribers. Every time an end user calls an API they have previously subscribed to, they must first authenticate to API Connect using their unique key (since their usage must be tracked, billed and possibly limited). Once authenticated to the API gateway, all subscribers invoking usage instances for this API will be authenticated to the same API endpoint using the same authentication scheme and credentials as created when setting up the API.
Their are several choices of back-end authentication schemes when using external API endpoints. See this tutorial for more information and links to further resources:
https://www.ibm.com/support/knowledgecenter/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/tutorial_apionprem_security_OAuth.html