Test a Cache Writer (Data Readers)
Cache Writers / Data Readers read and replicate data from a connected system. When testing, you need to verify:
Data Accuracy - the replicated data is in an accurate state with respect to:
Value equality
Formatting
Data Completeness - all the data representing this object is present when read from the connected system.
Some things to consider:
Should empty properties be written as null or not written at all?
Does the connected application allow for custom fields or the renaming of fields? Are those written correctly when present?
Are there any fields that are sent conditionally based on the values of other properties? If so, you’ll need to test all variations.
All read types are handled correctly. You should test:
Adding a new record
Updating an existing record
Deleting an existing record
A typical test plan is used to ensure all necessary scenarios have been tested. Verify a cache writer includes:
Running the cache writer once to verify a complete write of the data in the connected system. For information about how to create and run a service, see the About Jobs documentation.
In the Job History, the count expected is the same as the logs and that there are no errors.
The objects display as expected in the Data Cache Explorer.
Testing that the cache writer picks up new objects.
Add a new object in the connected system (after the initial cache write).
The object displays correctly in the job history logs.
The object displays correctly when viewing the record in the Data Cache Explorer.
Testing that the cache writer picks up changes to existing objects.
Update an existing object in the connected system and verify that it is detected as an update in the cache writer and verify the change in the Data Cache Explorer.
If a change in the connected system can affect others, verify that change is also detected as expected
Testing that the cache writer removes deleted objects
Delete an existing object (or the new one you created above)
Verify the object is deleted in the logs
Verify the object is no longer present in the Data Cache Explorer
Test an Action Processor
Action Processors write data to a connected system. To run an action processor, create a flow that includes a step that runs your action via the Connector Action step.
Afterward, test that the action output by verifying:
The action outputs look correct in the run history
The logs look correct in Job History -> Not Scheduled
The object displays correctly in the Data Explorer
Any changes are reflected correctly in the connected system
These checks should be run for every new Action Processor added to a Connector.
Action Processors can handle a variety of different action types - here’s a list of the different variants and what needs to be checked for each:
Adds (Adding one or more objects into the connected system, will fail if an object matching the key exists)
Verify all variants of key value references used by the action correctly detect matches in the connected system either create a new object successfully or fail gracefully if that is the expected result
Verify that defaulting logic works correctly when submitting an object with only the minimum required fields filled (minimum data set)
Verify that all properties are sent correctly when filling out all possible fields (maximum data set)
Verify the functionality of any custom validation or defaulting logic that was written into the action processor (rather than being handled by the connected system’s API)
Changes (Updating one or more objects in the connected system, will fail if no object matching the key exists in the connected system)
Verify all variants of key value references used by the action correctly detect matches in the connected system and either successfully update the referenced object or fail gracefully when no object matches the provided key
Verify that defaulting logic works correctly when submitting an object with only the minimum required fields filled (minimum data set)
Verify that all properties are sent correctly when filling out all possible fields (maximum data set)
Verify the functionality of any custom validation or defaulting logic that was written into the action processor (rather than being handled by the connected system’s API)
Upserts (A hybrid action that can be used for both add and change actions (will add rather than fail if no object in the connected system matching the key exists)
Verify all variants of key value references used by the action correctly detect matches in the connected system and either update an existing object or add a new one depending on whether an existing object matching the key existed prior to running the action
Verify that defaulting logic works correctly when submitting an object with only the minimum required fields filled (minimum data set)
Verify that all properties are sent correctly when filling out all possible fields (maximum data set)
Verify the functionality of any custom validation or defaulting logic that was written into the action processor (rather than being handled by the connected system’s api)
For upserts, the above tests need to be run for both adding new objects and updating existing objects
Deletes (Removes the object matching the provided key values from the connected system)
Verify all variants of key value references used by the action correctly detect matches in the connected system
Refresh Cache (An action that effectively runs the cache writer but is initiated in a flow rather than from a scheduled run of the service)
Verify that the cache writer runs correctly - perform all checks referenced in the Testing Cache Writers (Data Readers) section of this page
For all of the above, verify:
The action outputs look correct in the run history
The logs look correct in Job History -> Not Scheduled
The object displays correctly in the Data Explorer
Any changes are reflected correctly in the connected system