Get immediate response from WebHook URL

[nitech]

I'm hosting my site at Hyperlane. The URL structure of a site in dev environment looks like this:

https://dev-sitename-[random-uid].hyperlane.co/

When I try to call the URL for the webhook from an Azure Logic App, it times out.

So my question is: Is this supposed to work in trial mode (I haven't purchased Enupal Backup yet)?

[nitech]

When I try to call the URL directly, it does answer with:

{"success":true,"message":"running"}

... after quite a long time. I suspect that what's happening in Azure Logic Apps is the the HTTP request is automatically aborted after x seconds, causing the backup request also to be aborted on the server.

What if you could make the webhook return a response immediately. This could look like the following:

{
    "status": "running",
    "backupId": "123",
    "statusCheckUrl": "https://yoursite.com/enupal-backup/status/schedule?key=H4XX0R&backupId=123"
}

Then you'd poll the statusCheckUrl until it yielded a success or failure.

[andrelopez]

Hi @nitech Yes, the webhook should work on the trial. Right now the only notification method is via email, however we could a feature request to send a webhook URL notification to notify any other systems that need to know when the backup is finished or evaluate your proposal above.

[nitech]

Just to confirm: Azure Logic App's max timeout is 120 seconds.

Which means that I cannot use Enupal Backup from Azure Logic Apps as long as there is not an immediate response. I haven't looked into the code of the plugin, but since the response I get is "message" : "running" - which comes after a few minutes - I suspect you could easily move the "running" response further up in the code tree. Right?

[andrelopez]

@nitech Thanks for following up. Could you please update your plugin to v1.5.0? You may need to update the cron job (please let me know how to add this to azure and I'll update our docs) to execute the craft queue, please follow our instructions here https://docs.enupal.com/enupal-backup/schedule/webhook.html

The response that you will get on this update will be

{"success":true,"message":"queued"}

That means that the backup is added to the Craft queue and the time response of the webhook URL should be fast.

The backup will be executed whenever craft queue/run is executed or when you access to the cp, that's the reason of why the second Cron is needed.

Please let me know if you have any questions

[nitech]

Thanks for the update @andrelopez. It works.

Regarding Azure Logic Apps and how to set it up - just to make sure there is no misunderstanding here - I am triggering the WebHook URL. There is no running of Cron Jobs from Azure.

Azure Logic Apps is about automating workflows without code. The service goes kind of hand in hand with Azure Function Apps - which is a "Functions As A Service (FAAS)" architecture. Serverless code in other words. You don't have to relate to servers, you just run small blocks of functionality. I believe most cloud providers of a certain size has a similar approach.

In Azure Logic Apps, you add blocks of functionality. My implementation simply calls the Enupal Backup WebHook every night:

The JSON for the logic app looks like this:

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "HTTP": {
                "inputs": {
                    "method": "POST",
                    "retryPolicy": {
                        "type": "none"
                    },
                    "uri": "[Enter Enupal Backup WebHook URL here]"
                },
                "runAfter": {},
                "type": "Http"
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "parameters": {},
        "triggers": {
            "Recurrence": {
                "recurrence": {
                    "frequency": "Day",
                    "interval": 1,
                    "startTime": "2020-06-25T00:00:00",
                    "timeZone": "Romance Standard Time"
                },
                "type": "Recurrence"
            }
        }
    },
    "parameters": {}
}

[nitech]

Just noticing here that the backups are actually not triggered until I log into the system (I am guessing that triggers a run of the queued items).

Why is that, and what can I do to fix it?

Before upgrading the plugin, I had checked the "Run job in background" lightswitch. Could it be that the TRUE setting for this option is still in the database, and that is what causes this behavior? (At the same time, I looked at your latest commits, and I see you completely removed the code that enqueues the backup)

[andrelopez]

@nitech Yes, on the latest update me removed that behavior (following the recommendation from the Pixel & Tonic team https://github.com/enupal/backup/issues/29), we only add the backup to the queue. You need to add a Cron Job just after the backup URL is triggered that executes the craft queue, please go to Enupal Backup -> Settings -> Schedule and copy your Cronjob Example into your crontab on your server, our local cronjob looks like the following

# Add Enupal Backup to the queue
10     3    *    *    *  curl --request GET 'http://craft3nitro.test/enupal-backup/schedule?key=paWgQOBhgY'
# Executes the Enupal Backup 1 minute after
11     3    *    *    *  cd /home/ubuntu/sites/craft3nitro && php craft queue/run

[nitech]

Ah... I don't have the possibility to run Cron Jobs at my current hosting provider (Hyperlane).

And I don't quite see how it would make sense to be able to trigger a WebHook if you still have to "effectuate" the WebHook's action by triggering a cron job ;-)

Perhaps there is a way to trigger the processing of the queue in Craft CMS from a WebHook?

(also found this plugin, which to mee seems like a replacement for a "run every minute"-cron job)

[andrelopez]

@nitech That plugin looks like a great solution to avoid the second cron job. Could you please let me know if that works for you? and I'll update our docs as a possible recommendation to consider for other users.

[nitech]

@andrelopez It seems to work as we hoped. I have only tested it once, but it behaves as expected.

[nitech]

Confirming that it's still working. Nice solution. :-)