Introduction
This article provides the summary of Managing – Webhooks, Accounts, Triggers on webMethods.io Integration.
Managing Webhooks, Accounts, Triggers
webMethods.io Integration lets you to create integrations that can be invoked with different patterns. For example,
On-demand: An integration that can be invoked with a webhook with or without a payload on a need basis. For example, with a HTTP Callback endpoint.
Pooling/Scheduled: An integration that can be scheduled (Clock trigger) to pool for every 1 hour to synchronize the data between two systems – i.e., Data Integration. For example, synchronize the Sync Salesforce Lead to Marketo Lead.
Event Driven: An integration that will monitor a resource of an external system. For example, monitor a Device on Cumulocity IoT for Alarm and on alarm create a Zendesk ticket for the support engineer.
These are referred as Triggers on webMethods.io Integration. The triggers and other remaining connectors on webMethods.io Integration would need to have connections with the external systems configured. These are referred as Accounts on webMethods.io Integration.
Webhooks, Accounts and Triggers are in general created and managed by Developers during the implementation of an integration. These configurations are also available for Platform Administrators under Projects -> Configurations. Configurations under Projects would provide the catalogue of all the Webhooks and their tokens, All the external accounts used in the works of the Projects and trigger conditions that monitors the external systems. These configurations are important for promoting/publishing the projects to the higher stages. A holistic view is required for the Platform Administrators/Developers who would manage and perform the deployment of the projects.
Also, you might want to have different authentication tokens, different accounts and different trigger configurations for different environments. This view would help to plan and mange such activities.
Webmethods.io Integration allows the below three roles. Admin – who can manage the users, roles and Projects. Developer – Who can manage all the projects. Custom Project Specific Role who can create integrations only selected Projects.
Usually Developers tend to create lot of accounts that are no longer used in the projects. For example, if an account is created for the initial versions of the integration and later it is removed from the integration it is still maintained at the Project Configuration level. This is because of the versioning support on webMethods.io Integration that lets you to restore at any point of time.
Platform Administrators in general would not have the understanding on type of integrations developed and configurations used. Projects Configurations view bridges this gap between Admin and Developers.
Its recommended to follow a naming convention for Account Names so that the developer would recognize the accounts already configured and use them during their development. For example, development tenant you can create Account with the name Dev_system.