Add recovery options to ACE SalesForce Discovery Connector

Many thanks for teh reply and explanation Ben.

We appreciate the issues here and note that we have the same underlying issue in several other places (for example managing sequence numbers in integrations or other data we need to persist outside of a single instance of an integration) where we have created internal micro-services to encapsulate this behibd dedicated internal APIs, backed in our case by internal MySQL pods. Another example is that we have lived for years with the SAP adapters using a shared queue manager and queue to store GTID details.

We would be OK setting up REDIS but we note the dependencies this creates to provide dependant containers. If we were implementing this ourselves, as I said, we would probably encapsulate the function behind an API call micro-service and that might simplify our connectivity/security issues too.

Hi Richard,

Thank you for taking the time to raise this requirement (and also thanks for the strong back channel contextual conversations through Anthony O'Dowd on your IBM team, and David Crighton in L3 Service). We feel positively towards this requirement and we can see the value it would bring. As part of a wider architectural drive to support all discovery connector capabilities within the ACE integration server process (both deployed as part of Toolkit authored message flows and Designer authored message flows) as you might expect this is already on our radar. There are several moving parts which would be required in order to enable us to provide a solution. We expect to address these technical challenges through the next few mod releases of ACE, but felt it was worth outlining some potential milestones on that journey here, so that if there is radio silence for a while, you can at least rest assured that "we get it" and understand the required trajectory …

In providing a solution to this problem we require a means of storing the id that has last been successfully processed. Using an architectural component that could persist this value outside of one specific running container is our most likely favoured approach here (eg Redis or Kafka). As noted, we actually already have a means of achieving this in our managed public cloud service. In this situation we also need to pass the runtime container two further pieces of configuration - a "policy" with connection information for the third party component such as Redis, and security credentials which should be used when connecting. In the case of the public cloud service, this information (connection properties and security credential) is owned by "the service" as opposed to "the user". In the case of a software installation (eg in ACE Certified Containers), "the user" might own both these pieces of information. We suspect that we would utilise policies, credentials and an ACE integration server vault for storing this information. This means we need servers to be able to connect to multiple vaults (at least two - an "internal private" one and an "external user" one) which we might choose to hide within the product, or externalise so that it can be exploited for other use cases.

Requirement is accepted and moved to Future Consideration status.

Hi - thanks for raising this: Passing it onto the App Connect team for appopriate consideration.