We are encountering inconsistent results with DocuSign Connect integration where some envelope transactions are received by the listening server while others are not. This DocuSign integration involves two web servers with load balancing (listening app on both). The existing log details lack enough troubleshooting data to describe reason for the Connect failure events.
DocuSign Connect logs the responses it receives from the customer's Connect servers (or "listeners"). But Connect is merely the client of your servers.
The best logging will be your servers' logs.
Are your servers processing the incoming notifications synchronously or putting the notifications messages onto a queue and then later processing the messages asynchronously? The latter is a more reliable and recommended pattern.
You may want to consider switching to a PaaS solution that incorporates asynchronous queuing:
If you use a PaaS (Platform as a Service) system such as AWS or Azure, the cost of the intermediate system will be zero (AWS) or very low (Azure, etc) for as many as a million messages per month.
In addition, the PaaS pattern will enable your application to receive the notification messages from behind your firewall, with no changes to the firewall.
More information: https://www.docusign.com/blog/dsdev-webhook-listeners-part-4/
Code examples for AWS, Azure, Google Cloud for C# .NET Core, Java, Node.js, PHP, and Python are available from DocuSign’s GitHub repository. See the repository listing via this link. The repos all start with Connect-
After you receive a notification message, your application can use it to trigger a download/storage of the envelope’s documents; to start a new process since the envelope has now been signed, etc.
Related
I'm reading the very limited information about Azure SignalR service as well as the quick start guide and want to make sure I'm understanding this correctly.
We still seem to have a hub and if I understand this correctly, the function of Azure SignalR service is to simply push the messages to connected clients.
In my case, I store the history of chat so by hitting the hub first, I'm able to still use my backend logic to persist chat history or do any other processing that I may want. Then simply allow Azure SignalR service to push the data to connected clients.
The main benefit seems to be handling the scaling of the service.
Am I getting this right?
Yes, you are totally right.
You will use exactly the same API of ASP.NET Core SignalR to write your business logics, which means you can persist whatever you want when the messages from clients hit your hubs.
Azure SignalR Service will be the underlying transport between your app server and connected clients. For example, when you want to broadcast messages to all your clients, you actually only send one message to Azure SignalR Service and the service will broadcast the message to all clients for you. So that you don't have to worry about the scale-out. Azure SignalR Service will handle the scaling-out for you.
You understand correctly.
SignalR is not yet ready for production (when speaking about ASP.NET Core), SignalR for ASP.NET MVC has been around for a while (stable).
SignalR consists of 2 pieces: server and client. The server is as you describe: a "hub" that you can use to push information to clients.
On a webpage you load a piece of generated javascript (generated automatically from your hub definitions). Basically you let your website visitors (clients) connect to the hub through signalR's mechanism (signalR will choose the proper way to connect depending on the browser), and then 'subscribe' to the different methods you have active in your hub.
The workings are simple: whenever you call code in your hub (can be from clients, or from backend code) communication is automatically handled for you to all subscribed clients.
Note: If you are running this on an azure web app: enable the "always on" setting, and set the "websockets" toggle to "enabled", otherwise you'll see strange behaviour.
Note2: The RC version for signalR core 1.0 has just been released (7th of may 2018) so it might be a while before this software starts becoming stable and available through the public nuget/npm channels.
Given an Azure hosted Web Role with a highly-available WebAPI (say 99.95%, as per https://azure.microsoft.com/en-us/documentation/articles/resiliency-disaster-recovery-high-availability-azure-applications/) application that has ~1000 clients. Client is a ReactJS application. The WebAPI application will push notifications tailored to specific client groups (e.g. not all client users are interested in all events, but >1 user may be interested in the same event).
From reading the SignalR documentation and playing with some samples it feels like SignalR Groups will help us flow the right events to the right ReactJS application instances. Additionally we would use one of the SignalR scale out providers to make sure that the we push to the clients from the right WebAPI server instance.
Question: How do applications recover when the "right WebAPI" instance becomes unavailable?
I can imagine a server-side active/passive scheme with some complexity around making sure there is at least one 'server' for each Hub Client...but can a Server connect (in an unsolicited way) to a Hub Client? Would we have each Hub Client connect (when registering for a Group) to >1 Server?
How have applications solved this issue with SignalR?
I think I missed the obvious point that the scale-out providers and the back plane provide the very protection that clients need against servers that go-away. Clients don't connect to a specific server, but to a load-balanced name.
I have a question that is confusing me what are the differences between the types of service bus, the brokered messaging and the relayed messaging? I am not looking for it from the development perspective but I want to understand more the concept and the differences between them.
Thank you.
Service Bus Relay and Service Bus Brokered Messaging are both mechanisms for developing distributed and hybrid applications. However, they target different development and access patterns.
Service Bus (SB) Relay provides a simple & secure way to do service remoting, i.e., it enables you to securely expose a service hosted on a private cloud to external clients. As is the case with service remoting scenarios, clients explicitly invoke the methods exposed by the "Relayed" service. The primary advantage of SB Relay is that the service can be exposed without requiring any changes to your Firewall settings or any intrusive changes to your corporate network infrastructure.
SB Brokered Messaging on the other hand provides a durable messaging platform with components such as Queues, Topics and Subscriptions. These can be used to implement complex patterns such as publish-subscribe and temporal decoupling between different parts of your application. Since the brokered messaging infrastructure can reliably store the messages, the senders and the receivers do not have to be online at the same time, or do not have to process the messages at the same pace.
Relayed messaging is thus appropriate for scenarios where you have a service that you want to expose to external clients. Clients interact with the "Relayed" service in the same manner that they would if they were on the local network, except that they access it via the SB Relay endpoint. Since this is a service remoting scenario, response is immediate subject to network latency. However, if for whatever reason the service is unavailable at that moment, the client's request will always fail.
In the case of brokered messaging, since the send & receive operations are decoupled, the sender can continue to send messages that are reliably stored on the service regardless of whether the receiver is online or not. However, the tradeoff for this resiliency is that the request will be processed subject to receiver's ability to retrieve and process the message.
I think the main difference is the synchronous vs asynchronous nature of connectivity.
Where relay is mostly a firewall friendly way to expose web services to the public world (even behind firewalls, NAT devices, etc), messaging is more of a way to exchange in an asynchronous way messages over queues and topics. (look at it as the next version MSMQ with cloud support :))
Everything depends on the scenario, but if you are looking for
- Routing (pub/sub)
- Loose coupling sender & receiver
- Load leveling
Then you should definitely go for messaging.
If you want to make your service easily reachable for the outside world, relay service is your friend.
From Azure's site:
Relay
The Service Bus Relay service enables you to build hybrid applications
that run in both a Windows Azure datacenter and your own on-premises
enterprise environment. The Service Bus relay facilitates this by
enabling you to securely expose Windows Communication Foundation (WCF)
services that reside within a corporate enterprise network to the
public cloud, without having to open up a firewall connection or
requiring intrusive changes to a corporate network infrastructure.
Relay also handle load balancing for you (you can have multiple applications listen at the same endpoint for the majority of the bindings).
Brokered Messaging
The second messaging solution, new in the latest release of the
Service Bus, enables “brokered” messaging capabilities. These can be
thought of as asynchronous, or decoupled messaging features that
support publish-subscribe, temporal decoupling, and load balancing
scenarios using the Service Bus messaging infrastructure. Decoupled
communication has many advantages; for example, clients and servers
can connect as needed and perform their operations in an asynchronous
fashion.
Brokered messaging includes Queues and Topics / Subscriptions that allow you to send / receive messages asynchronously.
The main difference is that for relay, you have applications listening at an endpoint. When you send a message, the application processes that message when it is received. For brokered messaging, the message is stored when it is received by the client and can be processed at any time.
I’m designing a backend that allows users to establish a TCP socket with it and send/receive stuff along this socket (using a pseudo-protocol I’ve made up) in real-time.
It has to be scalable – i.e. architected on a cloud host. Currently I’m evaluating Windows Azure.
To achieve scalability the application will run on several Web Role Instances. Meaning the users’ TCP sockets will be split across several instances (via a load balancer).
This backend is an event-driven application – when a user sends something to it the message should be passed on to all other connected users.
This means there must be a reliable way to send messages from one Web Role Instance to all other Web Role Instances. As far as I understand, this is what inter-role communication refers to.
Using Service Bus, is it possible for all Web Role Instances to subscribe to a Topic and publish messages to it? Thus implementing the event-driven requirements of my distributed application?
(If not then I’ve misunderstood what this article is about: http://windowsazurecat.com/2011/08/how-to-simplify-scale-inter-role-communication-using-windows-azure-service-bus/)
I wanted to find this out before delving too deep into learning C#, .NET and Windows Azure development.
Thank you for your help.
Yes, using the service bus, all the web roles could send messages to a single topic and each role could have unique individual subscriptions to that topic, such that they all receive the messages sent.
Clemens Vaster has implemented an extension to SignalR using the service bus. It is possible that SignalR + the Service Bus may meet the needs of your project, including the TCP socket implementation.
http://vasters.com/clemensv/2012/02/13/SignalR+Powered+By+Service+Bus.aspx
I have 2 web applications running in a web role and I only run single instance in the azure cloud. I would like to send and receive notifications between these 2 applications and any outsider should not have access to them.
That means, web service in both of them are out unless there is a
way to block outsiders from accessing a web service and only a
request from same system would succeed (May be vip and request ip
comparison would do, anything beyond that?).
File system watchers. Create a LocalStorage and use it in both
web apps and watch for files webappA and webappB in each other.
Use Azure Storage Queues.
MSMQ - not interested as its not supported in azure.
Could you please list other options available for me in azure web role
? Thanks in advance.
Note: Please avoid suggesting Internal Endpoint as I am running only a single instance with 2 web applications running in it.
You can set up "private" web services to listen on Internal endpoints. These are not accessible via the outside world. You could have a WebAppOne endpoint and WebAppTwo endpoint, both marked Internal. You then just query the role environment to discover the assigned port for each, and fire up your ServiceHost.
Or... you could use a queue to pass information, as long as:
You're ok with it being asynchronous
You're ok with messages being looked at "at least" once
You're ok with messages possibly being looked at out of order
Or... your apps could write information to an Azure table. No need to expose the table to the outside world.