English Versión
MySQLAdmin or Other Relational Base
R1. Persist critical system information, allowing the integrity and execution of ACID transactions. Note: It is recommended to handle a relational database instance, due to the robustness they offer against NoSQL, taking into account that it is critical information in integrity (C.R.U.D).
If you consider that everything can be done in Mongo, document the justification and ignore the following requirements and tasks.
R1.1. The system must allow modeling business logic.
R1.2. The system must allow business data (invoices, PDFs, Users, etc.) To persist in the system's relational model.
R1.3. The system must allow C.R.U.D operations on the system model and these must be available for the other system components.
T1.1. Install the database instance related to the default configuration.
T1.2. Create the relational model to store the information corresponding to sales, invoices and PDFs.
T1.2.1. Create the diagram of the relational model.
T1.2.2. Create the DDL of the relational model.
T.1.3. Enable the administration console, documenting the connection string and the web administration path if you have.
MongoAdmin
The initial code already includes the use of Mongo as a database. This means that the C.R.U.D of users and parameters is already in the code. Note 1: The initial design contemplates the dynamism of the XML structure of each of the suppliers, unifying it in a single logical reading.
If it is considered that only direct reading will be left to XML separated into methods, document the justification and obviate requirements R2 and R3.
Note 2: Currently users are managed in Mongo, it is advised that this information should go to a relational database, to handle the integrity of the data in terms of updating and redundancy of the data.
R.1 The system must allow the non-critical realtime information that the application has to persist. Traces of customer costing queries on the page, among others.
R1.1. The system must allow to display a GUI to modify the system parameters. Currently, the code already allows this.
R1.2. The system must allow to perform the C.R.U.D of the realtime information.
R2. The system must allow to define a provider XML tag and assign it a value in EnviGO language (Mapping).
R2.2. Through a GUI, a label must be defined and mapped to the EnviGO language. Example: we have an XML with the following tag <PackagingType> YOUR_PACKAGING </PackagingType>, in the language of EnviGO it means PackageType so it should be assigned that PackagingType -> PackageType. So when you are going to create a query about this XML, search the fields by the EnviGO language and transform them into the language of each provider, achieving a single logical reading.
Note: only the tags that involve the EnviGO language must be stored, the others have to store them because the XML will already bring them. Therefore, only the tag with its respective path should be stored in the database as follows: {package type: {DHL: <body> <RateReply> <RateReplyDetails> <PackagingType>}}. Note: Remember that if you want to read directly from XML there is no need to develop this requirement, but think for a moment about the maintainability of the code when more suppliers arrive or when those who are changing their structure.
T1 A trigger must be created on the collection of the mapped fields, each time they change the trigger they must notify the ChangePublish component. The notification is only a push flag that changed.
ChangePublish
R1. The system must allow testing of the services of the providers and informing if they have changed or are down.
T1 A CronTab must be created with the process of making a default request to the different providers. Note: for this we recommend using SoapUI (free version) with the soaprunner.
T1.1. An email should be sent to the respective admin if the tests failed, indicating why they failed. The justification for the failure must indicate whether the supplier should be contacted directly or if corrective action should be taken. Note: if SoapUI is used, the confirmation and email sending script must be programmed in Groovy.
R2. The system must allow to notify the components involved in performing the mapping, which changed the mapping in the database.
R2.1. The system must allow traceability of the changes that have been made to the mapping.
T2 Each time you are notified of a change in the database (via the trigger) you must notify the CacheController component. Note: it may seem strange that instead of the trigger notification directly sending the mapping, you have to receive the notification that it changed and then perform the query.
This is done thinking that the change may have a post-processing that involves high complexity.
CacheController
R1. The component must allow updating the cache in Redis every time there is an update in the mongo or MySQL database. These critical data must be defined, but they are identified that the mapping is a critical data and the credentials of the services.
Note: because it is a transactional system, critical data must be identified to develop an effective cache strategy, in case of not finding critical data this component would tend to disappear.
R2. The system must allow the C.R.U.D to perform critical data.
ProviderSubscriberRequest (Required)
R1. The system must allow obtaining the XML corresponding to the request and response of any provider.
ProviderMapperRequest (Required)
R1. The system must allow mapping the language of EnviGO to the XML of the providers.
R1.1. The component must allow the values received per parameter to be injected into the requested XML file. This from the business language to the specific language of each provider. This component has to consult the memory mapping.
XMLOrchestrator
R1. The component must allow processing a EnviGO request, either for consultation or purchase. Note: This component is the one that orchestrates all the requested service with the functionalities of the other components.
ServiceAuthManager
R1. The component must allow obtaining the credentials of the requested service (OAuth2).
CacheRepository
R1. The component must allow to connect to the cache database (Redis) and make the corresponding queries to return to the different services.
EntityRepository
R1. The component must allow you to connect to the ACID database (MySql) and make the corresponding queries to return to the different services.
QueryServiceDelegate
R1. The component must allow to receive requests from the Frontend with the parameters to carry out the consultations of the shipping cost to the users. For this, the component must transform the parameters to the corresponding units of the service being requested.
Once the units have been transformed, you must consume the backend service of the XMLOrchestrator component and make the consumption to the supplier. When the response from the supplier is obtained, you must convert the units back to the origin where the customer needs them and finally add the corresponding EnviGO rate.
UnitConverter
R1. The component must allow converting the units that are stipulated, these units will be stored in the cache and once consumed they should be stored in the memory of the component with its current status.
R2. The component must allow the value of the different currencies to be updated.
EnviGORateManager
R1. The component must allow given a user profile and a specific service to return the effective rate to said customer.
OrderServiceDelegate
R1. The component must allow to receive requests from the Frontend with the parameters to perform the order queries to the users. For this, the component must transform the parameters to the corresponding units of the service being requested.
Once the units have been transformed, you must consume the backend service of the XMLOrchestrator component and make the consumption to the supplier. When the response from the supplier is obtained, you must store the invoice in PDF from the supplier and generate the invoice for EnviGO the first with the cost of the supplier the second with the price of EnviGO. Then you must respond to the user with the EnviGO invoice giving you the details of your order and the tentative dates.
AccessController
R1. The component must allow users to register, through third parties and in a normal way. For both you must allow to encrypt the password and add the salt to store in the database.
Once created the user must allow you to associate some roles and a label. The component must allow to authenticate a user who has already registered with the credentials stored in the database.
Prazo de Entrega: 01 de Novembro de 2019