/
NUTRINTG Mongo collections [WORK IN PROGRESS]

NUTRINTG Mongo collections [WORK IN PROGRESS]

sfmcToCdpFileFetcher_auroraTableProperties - queries responsible for uploading data into aurora db (wrongly named as fetcher collection even though it is currently used by processor service)
This collection will be probably only changed as result of request for support for new market data or errors in queries.

sfmcToCdpFileFetcher_erroredFileMetaDataStore - collection containing references to files with which there was a problem during upload to s3 fetched folder by fetcher service. There is also stacktrace here telling us what went wrong. Removal of one of those entries can be used to retry upload of file to s3

sfmcToCdpFileFetcher_fileMetaDataStore - collection containing references to files succesfully uploaded to s3 fetched folder by fetcher service. Removal of one of those entries can be used to enforce re-upload of file.

sfmcToCdpFileFetcher_progressMark - collection containing information about some file being in process of uploading to s3 fetched folder by fetcher service. This collection usually shouldn’t be modified and should be empty when nothing gets processed. There was few occurances when removing progressMark was necessary to restart uploading of file

sfmcToCdpFileFetcher_sftpProperties - collection with sftp which are being checked for new files by fetcher service. This collection will be probably only changes as result of request for adding new sftp as data source.

sfmcToCdpFileProcessor_versionControl - collection in which we track version of files. When due to admin interference we restart upload of some file we need to ensure it doesn't got mixed with old version of this file on aurora db. Version is responsible for differentiating it. This collection usually shouldn’t be modified.

sfmcToCdpFileSender_sentFiles -collection responsible to avoid re-uploading already uploaded file during retry logic. This collection usually shouldn’t be modified. If we want to retry uploading file to output sftp we would usually do it through regenerating message by set-analyzer and going through whole process again.

sfmcToCdpFileSetAnalyzer_bepMetadata - this collection takes similar role to sfmcToCdpFileSetAnalyzer_fullDeltas but for BEP files

sfmcToCdpFileSetAnalyzer_fullDeltas - this collection keeps track of batches of files on which processing got started. Removal of specific entry can be used to regenerate one of batches. It is good to remember that system only takes into account latest batches so removal of other batch for specific strategyCode will not restart process.

sfmcToCdpFileSetAnalyzer_strategyCodes - collection with list of strategy codes handled by system. Here are informations like: files needed for specific batch, output folder on destination sftp, processing type and analyzer type. This collection will be probably only changed as result of request for support for new market data.

sfmcToCdp_blockedStrategyCodes - listed of blocked stategy codes. This collection can be used to check errors and restart process. When set analyzer initiates processing of strategy code it puts blockade for which should removed at the end by sender. If something goes wrong then blockade will not be removed. Basically when we want to restart process after errors we should remove blockade manually plus if we want to retry it we should remove last delta beforehand.

sfmcToCdp_strategyCodeMapping - queries responsible for generating output files from aurora db. We also have here info about output file name. This collection will be probably only changed as result of request for support for new market data or errors in queries.

sfmctocdpfileencrypter_encryptedFiles - collection responsible to avoid re-encrypting already encrypted file during retry logic. This collection usually shouldn’t be modified. If we want to retry encrypting file we would usually do it through regenerating message by set-analyzer and going through whole process again.