advisors-excel-llc / aeconnect Goto Github PK

When data arrives from the streaming API or queues to be sent to SF, the data should be validated to determine whether it can be processed.

The main workload of the validation will be done by implementing the validator service and using Voters.

A specialized Voter will be implemented for the use of expression language in an annotation on the entity class and its properties/methods to make it easy to make simple determinations.

The expression language in the annotation will have context to the SF connection, the SObject metadata, the state of the current entity and the incoming data changes from SF (using the SF object and field names).

The Voter will have context to the SF connection and SObject metadata from SF.

When sObjects of the same type come through an inbound processor where one sObject is the parent of another sObject, the child entity that is created is orphaned because the child and parent persist to the data base at the same time.
The child entity searches for the parent entity to associate parent to child before they are both persisted, and therefore the search returns nothing.

Create Annotation Driver and configuration settings that will be cached and referenced when an entity is saved or a change occurs from Salesforce.

Entity properties annotated with SObject mappings will be checked against the changeset to determine the changes should be queued for outbound changes to SF.

Need to refactor the config and how it is interpreted in the CompilerPass to create services in a way that works with PushTopics, Platform Events, and ChangeEvents.

Sync records in bulk to and from salesforce via cli

Standard objects not supported by the streaming API will need to be intermittently polled for changes

Assess changeset on an entity an determine if any fields mapped to SF have been changed.

If so, the respective changes should be queued for the entity and handled in batch via a console operation running in a separate background process.

The queue should attempt to keep like objects grouped together when creating new objects, since SF processed the composite queue in batches of like objects with no more than 5 batches per request.

Any objects dependant on any objects not yet persisted, like requiring an SObject ID for a field, will need separated into a subsequent queue in order to reference the ID of the associated entity.

Syncs will be made in composite requests, prioritizing creations first, updates, then deletes, all in one singular request.

The streaming API will run in a background process via a console command. When new events arrive from the Streaming API, the payload/sobject message should be processed through the event dispatcher that will send data to internal listeners.

Amongst these internal listeners will include an entity mapping listener that will map the incoming data to the respective entity/ies.

Any handlers for generic or platform events will be able to register as a service using the Symfony event dispatcher service.