spryker/app-webhook
Composer 安装命令:
composer require spryker/app-webhook
包简介
AppWebhook module
README 文档
README
Provides SyncAPI and AsyncAPI schema files and the needed code to make the Mini-Framework an App with Webhook capabilities.
Installation
composer require spryker/app-webhook
Configure
App Identifier
config/Shared/config_default.php
use Spryker\Shared\AppWebhook\AppConstants;
$config[AppConstants::APP_IDENTIFIER] = getenv('APP_IDENTIFIER') ?: 'hello-world';
Testing the AppWebhook
You can test the AppWebhook as usual with Codeception. Before that you need to run some commands:
composer setup
With these commands you've set up the AppWebhook and can start the tests
vendor/bin/codecept build
vendor/bin/codecept run
Documentation
Webhook handling
This package is responsible to receive and handle webhooks. The package provides a controller that can be used to handle incoming webhooks.
The API endpoint is /webhooks and the controller is WebhooksController inside the Glue Application. This package is not handling webhooks on its own, you must implement the logic to handle the webhooks via the provided \Spryker\Zed\AppWebhook\Dependency\Plugin\WebhookHandlerPluginInterface, see the description down below.
Process in a Nutshell
- A webhook is received by the
WebhooksControllerand theWebhookRequestTransferis created. - The webhook content is mapped to a
WebhookRequestTransfer. - The
WebhookRequestTransferis passed together with aWebhookResponseTransferto the\Spryker\Glue\AppWebhookBackendApi\Dependency\Facade\AppWebhookBackendApiToAppWebhookFacadeInterface::handleWebhook()method. - The
handleWebhookmethod does:- Creates an identifier for this specific webhook.
- When it is not a retried webhook the webhook will be persisted in the database.
- In case of a retried webhook the webhook will be fetched from the database.
- When the number of retries exceeds the configurable allowed number of retries the webhook will be removed from the database and an exception will be thrown.
- Find the correct handler for the webhook and call the
handlemethod of the handler. - When the handler returns a failed
WebhookResponseTransferthe response will be persisted in the database. - When the handler returns a not handled
WebhookResponseTransferthe response will be persisted in the database with a message that was provided by the implementation of the plugin. - When the handler throws an exception the exception message will be persisted in the database.
- When the handler returns a successful
WebhookResponseTransferthe webhook will be removed from the database. - It returns the
WebhookResponseTransferto the controller.
- The controller formats the
WebhookResponseTransferinto a Glue response which will be either:- 200 OK in case everything went well.
- 400 BAD REQUEST in case of a failed response.
Retry Mechanism
In a case when a webhook can not be handled it is persisted in the database and will be retried with the next incoming webhook. The number of retries is configurable and can be set in the AppWebhookConfig::getAllowedNumberOfRetries() method.
There are numerous reasons why a webhook may fail. An exception is thrown, the plugin implementation returns a failed response or the plugin implementation returns a not handled response.
Another case could be an event is sent to the application before it is ready to handle it. For example, in the PreOrder payment of a PSP the order has not persisted yet and has no order-reference, but the PSP sends a webhook request about a payment state, in this case, the system has to wait until it can process the webhook.
Future improvements for the Retry mechanism
It may be helpful in the future to provide a console command that can be used to retry failed webhooks. This command can be used to retry all failed webhooks or only a specific webhook.
Configuration
Currently only the number of allowed retries can be configured. The configuration can be found in the AppWebhookConfig class.
Plugins
GlueApplication
\Spryker\Glue\AppWebhookBackendApi\Plugin\GlueApplication\AppWebhookBackendApiRouteProviderPlugin
This plugin provides the routes for the AppWebhookBackendApi module.
Extensions
\Spryker\Zed\AppWebhook\Dependency\Plugin\WebhookHandlerPluginInterface
This plugin can be implemented by any other module and has two methods:
\Spryker\Zed\AppWebhook\Dependency\Plugin\WebhookHandlerPluginInterface::canHandle(WebhookRequestTransfer $webhookRequestTransfer): bool\Spryker\Zed\AppWebhook\Dependency\Plugin\WebhookHandlerPluginInterface::handle(WebhookRequestTransfer $webhookRequestTransfer): WebhookResponseTransfer
The canHandle() method is used to check if a webhook can be handled by a specific module. F.e. you have two handlers one for order.created and one for order.updated you can check in the canHandle() method if the webhook can be handled by the module and return true or false.
The handle() method is used to handle the webhook. The method is called if the canHandle() method returns true. The method should return a WebhookResponseTransfer with the status of the webhook handling.
spryker/app-webhook 适用场景与选型建议
spryker/app-webhook 是一款 基于 PHP 开发的 Composer 扩展包,目前已累计 4.35k 次下载、GitHub Stars 达 0, 最近一次更新时间为 2024 年 06 月 26 日, 在 PHP 生态内属于活跃度较高的组件。
我们在过去多个企业项目中使用过 spryker/app-webhook 或与其功能相近的方案,如果你在选型或落地过程中遇到问题,例如 版本兼容、二次改造、私有化封装、与内部系统对接、生产 BUG 排查,欢迎联系我们协助评估。
基于 spryker/app-webhook 在你已有业务上做功能扩展、字段裁剪、UI 适配、与内部账号 / 权限 / 日志系统的深度对接。
线上偶发问题、内存泄漏、慢查询、并发异常等排查修复;针对高流量场景做缓存、队列、索引层面的调优。
承接完整的项目从需求 → 设计 → 开发 → 上线 → 长期运维;也可按月提供技术保姆服务。
统计信息
- 总下载量: 4.35k
- 月度下载量: 0
- 日度下载量: 0
- 收藏数: 0
- 点击次数: 7
- 依赖项目数: 2
- 推荐数: 0
其他信息
- 授权协议: proprietary
- 更新时间: 2024-06-26