Store service #30

[stfnltnr]

resolves #30

Added

Added new Service at.fhjoanneum.ippr.processstore for the process store. Service is running on port 12000 an registered at Eureka/DiscoveryClient

At the current state one Endpoint is available via the following Gateway API URL

localhost:10000/api/store/processes

Performs GET request to retrieve all stored processes from ippr_store.processstore. Authorization required.

Testing

Add data to ippr_store.processstore table

INSERT INTO ippr_store.processstore 
VALUES (1, '01.06.2018', 'test1', 'test desct asldfasd', 'name1', 123.123, 1);

INSERT INTO ippr_store.processstore 
VALUES (2, '20.06.2018', 't1231est', 'testasdas asda as asd as ad asd ad asd ad asd dd', 'name2', 222.222, 2);

Calling localhost:10000/api/store/processes should return:

[
    {
        "processId": 1,
        "processName": "name1",
        "processDescription": "test desct asldfasd",
        "processCreator": "test1",
        "processCreatedAt": 993052800000,
        "processVersion": 1,
        "processPrice": 123.123
    },
    {
        "processId": 2,
        "processName": "name2",
        "processDescription": "testasdas asda as asd as ad asd ad asd ad asd dd",
        "processCreator": "t1231est",
        "processCreatedAt": 1592668800000,
        "processVersion": 2,
        "processPrice": 222.222
    }
]

ToDo

• Add further endpoints to the ProcessStore

[stfnltnr]

I understand your concerns, I am not hundred percent sure how we should implement that. Since the ProcessStore is an own MicroService with its own DB ippr_store and Users have their own DB ippr_security.

Correct me if I am wrong, user upload processes and they are reviewed (all this is handled by ippr_security, User OneToOne mapping isn't a problem - user information of the uploader is stored). If a process is flagged approved it could/will be added to the store (ippr_store), based on the data provided via ippr_securtiy. :see_no_evil:

Any ideas how we could improve this process, should we run all our services via ippr_security

[amarbajric]

Yes I have already done a little bit of research. Mapping (foreign keys) between different schemes in MySQL is no problem regarding to some blog posts and docs from mysql. So the mapping should be no problem. We just have to think about how to get data between the store service and the sec. service. (i.e. if a process is uploaded, the store service needs to get user data from the sec. service first via eureka and then persist the new process)

While running all of our services in the same schema ippr_security is an alternative, I think it should not be a huge problem to do it across different schemas. I will try to also dig a little bit deeper into this topic in the next few days.

Other than that, I think we can merge it into the dev branch. BEFORE doing this, can you just merge the latest changes from the dev branch and resolve the issues in the CHANGELOG.md file?

[stfnltnr]

why do we not simply run the store within ippr_security and if a process is flagged approved it is shown within the store. Or will that result in some conflicts that I am not aware atm?

[amarbajric]

If I understand that right, you are suggesting to move ALL of the store logic (i.e. service) into the Gateway service and to also create all entities within the ippr_security schema? While this is possible, I have a few points to mention:

• Is the approach of using the ippr_security schema really appropriate because it is meant to only be used for User information and in this case now for organization information storage?
• Is it not possible to let the two services communicate via eureka and exchange the needed data and then do its work as intended from the beginning?
• Is it in general not a more tedious approach to split these two services and dont "pack" everything into one service (i.e. the gateway service)? Or are you simply concerned about the possible complexity and additional effort we need to implement it this way?

[tortmann]

why do we not simply run the store within ippr_security and if a process is flagged approved it is shown within the store.

I think that adding store logic to ippr_security kinda goes against to whole logic of a microservice based architecture and make it very hard to make large changes to the store logic in the future if it is tightly coupled with ippr_security schema since this is required at all times.

therefore i think that any new features (e.g. store) should be implemented in a seperate microservice /schema to avoid dependancies and stay in line with the initial microservice architecture approach of the project

Thoughts??