SendMail

DAS

1
Content
Preface .......................................................................................................................................... 3
Introduction .................................................................................................................................. 4
Structures ...................................................................................................................................... 5
Database.................................................................................................................................... 5
Status ..................................................................................................................................... 5
SendAttempts........................................................................................................................ 6
Processing flow ............................................................................................................................. 6
Audit log ........................................................................................................................................ 7
Technical specifications................................................................................................................. 7

2
Preface

This document aims to detail the specifications, functionalities and technical section of the
development of the SendMail system.

3
Introduction

The SendMail (SM) system will be a background service that must process and send emails from
an SMTP server to various recipients.

The processing flow will be subject to a series of controls and verifications regarding the content
of the information to be sent. Such data will be persisted at the database level, which will be
manipulated in order to build the structure that will be sent by email

The SM will be within the business reality of a document approval system (DAS). These emails
that it will send will correspond to different types of structures and events that are part of the
logic of the DAS.

4
Structures
To understand the operation of the SM, it is important to be clear about the different structures
involved in the logic of DAS, as well as their intervention in the new service.

• Company: Entity that refers to the institution that uses DAS to carry out its transactions
of goods and / or products, both as a seller of the same, or as a buyer.
• Document/Voucher: It is a document that proves the transfer of a good, the delivery in
use or the provision of a service.
• RUT: The Single Tax Roll or Single Tax Registry, also known by the acronym RUT, is a
unique number implanted in several Latin American countries, which was established as
a tax identification. It is the identifier of the company in the system.
Database
At the database level, the SM will work with the OutgoingEmails table, which stores the
information that will be sent by email. Each tuple there corresponds to an email to be sent.

The structure of the table is as follows:

• OutgoingEmailId: identity of the email

• To: email recipient
• From: sender of the email.
• Subject
• Body
• Attachment (stored as varbinary)
• Status: identifier that describes the status of the mail delivery process.
• CreatedDate: date the record was inserted.
• ModifiedDate: date the last modification to the registration was made.
• IsAlert: flag that indicates if the email is of alert type.
• SendAttempts: number of sending attempts in case of error.
• CompanyId: identity of the company that is sending the email.
• ReceiverId: identity of the user in the system that will receive the email (optional).
Status
The status of the mail delivery will indicate the current status of the mail in the system, as well
as the behavior and expected flow of execution. There will be 4 different states at database
level:

• 0: Not Processed
• 1: Sending
• 2: Sent
• 3: Error

5
SendAttempts
The function of this field is to determine the number of retries, in the scenario that the process
of sending an email has failed.

When a mail delivery fails, the error must be established at the log and database level, but it
must also be given the possibility of retrying the delivery, in order to correct the problem.

SendAttempts will be a counter, which will establish the number of times that the email will be
attempted to be sent in case of failure.

The counter limit should be determined at the application level (preferably in a value within a
configuration file). Once this limit is equal, no attempt will be made to send the email again,
leaving it permanently in error (3).

Processing flow

At the moment the SM is started, a series of pre-controls and validations are executed at the
structural level of the service, checking connectivity, ports, schemes and proxy configurations
(this last point may be optional).
After these controls and validations, the cyclical process of processing the data to be sent by the
service begins, which must follow an established order that will be detailed below.

1. The SM obtains from the OutgoingEmails table all the record whose status is not
processed (0) or those that the state is error (3) and SendAttempts < counter limit.
2. For each record, processing begins.
i. The status of the record is modified and persists to sending (1).
ii. The mail structure is built with the registration data obtained: Issuer, recipient,
subject, body. In case of having an attachment, it is also incorporated.
iii. An attempt is made to send the email.
iv. The flow is divided into two paths depending on the result of the delivery:
a. Sending mail successfully:
• Record status is updated to sent (2).
b. Error trying to send email:
• Record status is updated to error (3).
• The value of the SendAttempt column of the corresponding
record is increased by 1.
3. When the flow of all the records from point 2 ends, the execution of point 1 returns.

6
Audit log
In order to adequately monitor what happened in the service, an audit structure must be
implemented, in which each action that occurs in the processing flow will be recorded:

• Start of service.
• Service stop (if applicable).
• Start of flow.
• Obtaining data for sending emails.
• Attempt to send mail.
• Success when sending mail.
• Error sending mail.
• Change of states of the registry in BD corresponding to the mail.
• Any error registered in the service, with its corresponding indicative message.

Technical specifications

• The system must be a worker that simulates the execution of a background service that
is constantly running.
• Must be developed in C # using .Net Core technologies (version 3.1).
• It should be used as the definitive storage medium, SQL Server database.
• The deployment of the application must be done under Docker architecture (Linux
Container).
• The different variable configurations, settings, log file path, URLs, connectivity ports and
proxy credentials must be implemented in the YML file of the docker-compose.
• The log file generated during the processing of emails must be available if the
corresponding container is stopped.
• The functionality of sending emails will be implemented with the Rebex.Net library
(license already purchased).
• Once the project is approved, for a better understanding of the tool and its operation,
the developer will be provided with:
o Database schemas.
o Component with libraries and license from Rebex.Net.
o Any documentation that the developer considers necessary for a correct
implementation of the solution.
• The developer may suggest changes and implementations that optimize the process,
which will be subject to approval by the company.
• The source code will remain the property of the company, in order to carry out future
maintenance tasks. As well as scripts and schemas of the generated database.
• GitHub will be used as data repository and versioning control.
• For the monitoring, administration and management of the project, the Jira tool will be
used
• The service must accept Http proxy / SMTP proxy settings. The configuration (IP server,
port server, user, password must be implemented in the YML file of the docker-
compose).