Web services data dip connector deprecation
Genesys deprecated the web services data dip connector. For more information, see Deprecation: Genesys Cloud Bridge integrations.
Why was the connector deprecated?
Genesys is increasingly focusing on cloud technologies, which are scalable in ways that the installation and management of hardware and software inside customers’ firewalls is not. The company continues to devote more resources and energies to the development and support of cloud technologies and to strengthen its cloud deployment and delivery model.
Delivering services through the cloud offers many benefits to customers:
- Reduces on-premises hardware and software requirements, which decreases capital and operating expenditures.
- Gives customers better control over access to their data with increased security and auditing.
- Standardizes customer experiences in Genesys Cloud.
- Allows better support of integrations that exist completely in Genesys Cloud.
What is the alternative to the web services data dip connector?
The company recommends that customers of the connector migrate to the web services data actions integration or the AWS Lambda data actions integration, if AWS Lambda data actions are more appropriate for your workflow. The web services data actions integration not only performs the same functions as the web services data dip connector. The web services data actions integration has more functionality built-in, such as support for more HTTP methods and natively handled authentication. For more information, see About the web services data actions integration and About the AWS Lambda data actions integration.
How do I migrate to data actions?
The contracts of actions used with the web services data dip connectors are compatible with actions used with the web services data dip integration. You can easily migrate contracts in input schemas from actions for the old connector to actions for the new integration. In Genesys Cloud, download contract schemas from the web services data dip connector and copy them into contracts for new actions created for a web services data actions integration. For more information, see Add contracts to custom actions for integrations.
You can also easily remap attributes for actions in Architect. In Architect, map custom attributes from a Call Bridge Action to a Call Data Action. For more information, see Migrate interaction flows.
How do I access on-premises data?
Web services data actions integration
To use the web services data actions integration, you must create a publicly accessible HTTPS web service endpoint that the data actions integration accesses. You could use a port forwarding technology like ngrok or host your own web service in the cloud. By creating your own publicly accessible HTTPS web service endpoint, you control access to your data and have more transparency into the data integration process. You decide what type of authentication or certificate to use for the TLS handshake. The data traverses Genesys Cloud securely, using the same data flows that meet PCI compliance standards in the US.
To use data actions with an on-premises data source, implement a port forwarding service to allow access to web services that reside inside the corporate firewall. (Some examples include ngrok, serveo, alternatives to ngrok, or similar technologies that you are familiar with.) These applications allow more transparent control of access to internal resources than the Genesys Cloud Bridge Server, which the web services data dip connector used. This approach allows you to use authentication, which is not currently supported with the web services data dip connector.
AWS Lambda data actions integration
Another alternative is to use the AWS Lambda data actions integration with your on-premises solution. For more information, see Data actions with on-premises solutions overview, Workflow for data actions with on-premises solutions, and Example AWS Lambda data action with on-premises solution.
What do I have to maintain?
To access a local data store with the web services data dip connector, customers had to develop their own custom middleware that had a REST interface. The REST interface supported the simplified contracts and POST-only HTTP method of the connector. This middleware then proxied the call to the actual resource internally, often adding items like authentication and modified HTTP methods or actions. (In contrast, the web services data actions integration supports authentication and more HTTP methods.)
Generally, with the web services data actions integration, there is less to install and maintain. Also, the workflow is simpler; Genesys Cloud either communicates directly with the third-party service (if it is a REST or GRAPH API) or with the proxy application (if it does not support REST or GRAPH web services). For more information, see Workflow for the data dip connector.
Are data actions more secure?
If you use data actions in secure flows in Architect, the data actions are included in our PCI compliance audits. Secure flows allow the Genesys Cloud IVR to handle sensitive customer information safely and securely. For more information, see Secure call flows overview. In contrast, web services data dip connectors using the Bridge Server were not included in our PCI compliance audits; these connectors should not have been used to handle sensitive information covered under PCI, HIPAA, or other data regulations.