Refactor code to clarify import/export terminology

[scottsb]

The extension, both in the code and in the admin, seems to use the term "import" and "export" inconsistently. Both terms are used to refer to data flowing from Magento to Dotmailer.

For example, the class \Dotdigitalgroup\Email\Model\Newsletter\SubscriberExporter passes the data off to \Dotdigitalgroup\Email\Model\Importer to be handled.

This makes interpreting the code unnecessarily difficult.

[sta1r]

Hi @scottsb - thanks for your thoughts here.

As a rule, the logic is:

• Export = retrieval of data from Magento's own tables into our connector tables (e.g. Subscriber, Catalog, Guest)
• Import = transport of data from our tables to an "importer" queue table, and from there to Engagement Cloud via API call

That's the distinction we're aiming for, although for sure it seems we've got our terminology a bit tangled in some places. We'll tidy these up going forward.

[scottsb]

@sta1r Got it. So both "export" and "import" are used to refer to different phases of the data move from Magento into Engagement Cloud?

Perhaps I'm wrong, but I believe there are also some cases where data moves from Engagement Cloud into Magento, right? In these cases, what terminology is expected?

[sta1r]

Our connector is essentially a one-way data transport tool, moving data from Magento to Engagement Cloud. In terms of data moving the other way, there are no scripted syncs as such (or formal terminology), just occasional status checks and validation of data against matching records in EC. For example:

• Unsubscribes. In the Subscriber sync, we pull a list of recently suppressed contacts from EC in order to ensure contacts are marked as unsubscribed in Magento.
• We use the EC campaign send date to store against sent campaigns in our table (in some cases).
• Prior to processing abandoned cart campaigns, we check the batched contacts for their opt-in status in EC.