I was going through gitlab docs for webhooks but did not find how to setup the URL/endpoint.
If there are no pre-defined URLs then I have to create / manage URLs/endpoint, it is overhead because I have to manage the infrastructure and the write the code as well to create the endpoints .
So, are there any pre-defined webhooks ? , if yes , how to get that ?
further, my exact requirement is, whenever, merge request gets merged, I have to update one of the gitlab pipeline job to proceed further. is that possible through webhooks and event API ? if yes, any documentation for that please ? I see that webhook receiver is there but not sure if that will solve my requirement.
please suggest
The URL/endpoints configured in webhooks are designed to be received by external applications, either made by you or third parties. As stated in the docs:
Usually, you set up your own webhook receiver to receive information from GitLab and send it to another app, according to your requirements.
In other words, GitLab itself has no endpoints you can point to that will respond to a webhook you configure on the repo, aside from the few builtin receivers, like for slack notifications which are configured through integrations.
whenever, merge request gets merged, I have to update one of the gitlab pipeline job to proceed further. is that possible through webhooks and event API ?
Yes it's possible, but in order to get the effect you want, you'll have to implement the HTTP service endpoint to receive the webhook yourself.
Related
I'd like to receive all my personal GitLab notification that are normally sent as emails to my own private Slack channel.
I'm quite familiar with Slack incoming webhooks, and I also know that GitLab officially supports Slack integration.
But according to related GitLab documentation (https://docs.gitlab.com/ee/user/project/integrations/slack.html#triggers-for-slack-notifications)., the Slack integration seems to be designed to work only for particular project, providing all notification related to that project across all users.
I want to achieve something different. I want to get only my personal notifications, but across all projects I participate in (e.g. changes made for tickets assigned to me, review results, results of pipelines triggered by my etc.).
Is there any way how to do it using just the standard GitLab's Slack integration or standard GitLab configuration? I'm using GitLab Enterprise.
What I have tried already:
going through GitLab documentation
Google search for this problem (including stack overflow)
reading a few tutorials on GitLab ≤≥ Slack connection
Is there any guidelines/recommendations for the webhook URL that I can use for setting up the event notifications?
I am thinking of using something like this - /webhook/v1/{uniqueAppID}. The uniqueAppID changes for every envelope, I dynamically construct the URL and set it to the EventNotification object while creating the envelope.
The unique app id is used to track the response from DocuSign, So if at all there is any issue in parsing the response, I would know for which envelope/app id I have got the notification.
I read that the system will retry delivery for failures only after a successful acknowledgement is received from the webhook, In my case, it will be like having multiple webhooks. Will this setup cause any issues in retrying the failures? Does setting up the url like /webhook/v1?uniqueAppID={uniqueAppID} helps?
Thank You
Great questions.
First up, you don't have to use any kind of endpoint/URL schemes. You could have them all go one place. The information that you get from DocuSign in the payload would allow you to know everything you need about the envelope and if you need additional information - you could make API calls to determine this.
However, I would agree that if you need this information, using different endpoints would give you greater flexibility. Also, if it's different apps, you could, in theory, deploy them separately and thus the endpoint code would change without affecting other apps.
As for retry, this is done in case DocuSign does not get a 200, 201 or other HTTP response that's positive from your web server. If DocuSign gets 401 or 500 etc. If no response is received, DocuSign would retry again in 24 hours.
That should not impact your decision about the design.
One last thing to consider, you cannot be behind firewall/VPN etc. Highly recommend you consider a public cloud provider (Azure, AWS, Google) for your app to avoid networking issues.
When using envelope-level webhooks, the triggers and destination URI are embedded into that envelope. After the envelope enters a predefined state like 'sent' or 'completed', the writeback targets the URI that you provided. Unless you intentionally change this, it should remain envelope-specific.
This is different from our typical Connect setup, which would have a single URI per listener and envelopes writebacks would be directed to the listener URI at the time they're processed.
Any subsequent failure or retry attempts would follow the standard guidelines outlined here: How to get docusign webhook to retry on failure?
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..
I want to implement event notification webhook method into my app. I am using docusign-java-client SDK for docusign, but I am unable to find any example using SDK. Can anyone provide some example to achieve this?
I'm sorry to report that we (DocuSign) don't yet have a Java recipe for this. We do have a Python example. Java is on the list of things to do. Perhaps someone else can provide an example in the meantime.
Here is a general description:
First, set up your webhook subscription. You can have an envelope-specific webhook subscription by including the eventNotification fields in your envelope create request.
Or you can set up a more general subscription by using the "Connect" feature. You can setup Connect subscriptions either via the DocuSign web tool, or programmatically.
As part of the subscription you provide your url for the incoming XML notification messages.
To handle them, you write a small web app using whatever web app framework is easiest for you and your stack. Your web server will receive the incoming https calls from DocuSign.
You can see what the incoming XML messages look like by using the beta Recipe Framework. Run it on Heroku. Use the embedded signing recipe and click the button to see the Webhook / Connect messages. You can then see the sorts of messages that you will receive.
Your incoming message web server will simply parse the XML messages and then handle them accordingly.
Thanks for using the webhook system. Please ask more questions here if you have any issues.
We are doing an integration with DocuSign where users can submit documents stored in our system to DocuSign to get the documents signed. We have the DocuSign Connect feature working in our demo account. We can process messages from DocuSign successfully.
We were concerned that getting users to add a Connect Configuration themselves may be too challenging for some and it will be error-prone.
I see now in the documentation that it is possible to automatically get DocuSign to push notifications by passing the information in the EventNotification attribute when we call createEnvelope. Is this an acceptable way to get push notifications from DocuSign? Will this cause issues with getting the integration certified?
Is there any other way to get Connect configured easily in customer accounts?
This is an old question, but I wanted, for the record to have answers, since it's important to anyone who may be reading this.
We see now in the documentation that it is possible to automatically
get DocuSign to push notifications by passing the information in the
EventNotification attribute when we call createEnvelope. Is this an
acceptable way to get push notifications from DocuSign?
Yes, it is. It's a very good way in fact, to reduce polling and make your app better. We highly recommend that you use EvenNotification and sign-up for events going through a webhook to your app such that you can handle them in your code only when they occur, instead of polling DocuSign APIs repeatedly.
Will this cause issues with getting the integration certified?
The opposite is true. If you use polling you may have issues being certified. Using connect events with a webhook is one way to avoid the need for excessive polling which could cause issues with the certification.
Is there any other way to get Connect configured easily in customer
accounts?
You can configure connect like you suggested using EventNotification at the envelope level. This approach works well for ISVs since you don't need your customers to have admin access to their accounts.
The other option is account-level connect configuration, which does require admin level access and there are some other limitations. This approach adds the connect webhook for all envelopes in the account. So it may or may not be better, depending on your scenario.