User Tools

Site Tools


sis_developer_manual

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
sis_developer_manual [2022/09/07 08:59] – [Building and Running Backend] ghacheysis_developer_manual [2024/03/11 01:52] (current) – [Packaging the Frontend] ghachey
Line 31: Line 31:
  
  
-==== Built Tools and Package Manager ====+==== Build Tools and Package Manager ====
  
 A collection of auxiliary tools not part of the actual application but used in automating deployment, frontend package management, etc. are also used: A collection of auxiliary tools not part of the actual application but used in automating deployment, frontend package management, etc. are also used:
Line 39: Line 39:
   * [[https://www.npmjs.com/|NPM]] will be installed with NodeJS above. It is the package manager and is used mainly to install dependencies and other tools used by the frontend. You can see the currently used npm packages in ''packages.json''.   * [[https://www.npmjs.com/|NPM]] will be installed with NodeJS above. It is the package manager and is used mainly to install dependencies and other tools used by the frontend. You can see the currently used npm packages in ''packages.json''.
  
 +<note warning>The Pacific SIS build tools is easier to setup with the NodeJS LTS version 16. The latest LTS 18 at the time of this writing requires handling a SSL obsolete method used by webpack.</note>
 ===== Setting Up the Development Environment ===== ===== Setting Up the Development Environment =====
  
 The easiest way to get a development environment and start developing on the Pacific SIS is on Windows with instructions below. The easiest way to get a development environment and start developing on the Pacific SIS is on Windows with instructions below.
  
-==== Main Development Tools ====+==== Download and Install the Main Development Tools ====
  
 Most developers currently use Visual Studio, Visual Studio Code, dotnet 6.0, MySQL, NodeJS/NPM. And SourceTree/Git is useful to manage code evolution: Most developers currently use Visual Studio, Visual Studio Code, dotnet 6.0, MySQL, NodeJS/NPM. And SourceTree/Git is useful to manage code evolution:
 +
 +
 +<note warning>Regarding step 4. below. The Pacific SIS build tools is easier to setup with the NodeJS LTS version 16. The latest LTS 18 at the time of this writing requires handling a SSL obsolete method used by webpack.</note>
  
   - Download and install [[https://git-scm.com/|Git]]   - Download and install [[https://git-scm.com/|Git]]
-  - Download and install latest [[https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx|Visual Studio]] (developers mostly on 2019 or 2022).+  - Download and install latest [[https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx|Visual Studio]] (developers mostly on 2022).
   - Download and install [[https://dev.mysql.com/downloads/|MySQL Community Version]] (the server and workbench).    - Download and install [[https://dev.mysql.com/downloads/|MySQL Community Version]] (the server and workbench). 
   - Download and install latest LTS [[https://nodejs.org/en/|NodeJS]].   - Download and install latest LTS [[https://nodejs.org/en/|NodeJS]].
Line 57: Line 61:
 The best way to start work on the Pacific SIS is to fork it in your own Github account. If new to forking read [[https://docs.github.com/en/get-started/quickstart/fork-a-repo|Github's Fork a Repo Documentation]]. Then clone your own forked Pacific SIS into your development machine. If new to cloning read [[https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository|Github's Cloning a repository]] The best way to start work on the Pacific SIS is to fork it in your own Github account. If new to forking read [[https://docs.github.com/en/get-started/quickstart/fork-a-repo|Github's Fork a Repo Documentation]]. Then clone your own forked Pacific SIS into your development machine. If new to cloning read [[https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository|Github's Cloning a repository]]
  
 +The Pacific SIS source code can be found at [[https://github.com/PacificEMIS/Pacific-SIS|Pacific SIS]].
 +
 +<note tip>When doing a fork, you are prompt by Github whether you only want to include the Master branch. Uncheck that to get all the branches. This way you will have access to the Development branch containing all the latest code for testing.</note>
 ==== Visual Studio Setup ==== ==== Visual Studio Setup ====
  
Line 93: Line 100:
  
 The backup will need access to the databases and this is done in the ''API/opensisAPI/appsettings.json'' file as shown below. The backup will need access to the databases and this is done in the ''API/opensisAPI/appsettings.json'' file as shown below.
- 
 <code javascript> <code javascript>
 { {
Line 117: Line 123:
  
 {{ :sis-developer-manual:catalogdb-1.jpg?nolink |}} {{ :sis-developer-manual:catalogdb-1.jpg?nolink |}}
 +
 +In production the name of the database should both:
 +
 +  * Be the hostname in the URL (e.g. a system hosted at https://pacificsis.pacific-emis.org would have a database called pacificsis)
 +  * Have the correct tenant_name in the catalogdb database configured as above to pacificsis (to use the same example as above)
 +
 +In development, it may be more convenient to use the database name opensisv2_ef6 at the moment. That way it does not matter what is in the development URL (typically http://localhost). In this case only:
 +
 +  * Have the correct tenant_name in the catalogdb database configured as above to pacificsis (to use the same example as above)
 +
 +A screenshot of a developer's machine could look like this where the pacificsis was a dump of the production system online and the opensisv2_ef6 is an exact same database that was created simply with a different name using a no schema options (i.e. no database name specified at dump but created during import)
 +
 +{{ :sis-developer-manual:database-setup-example-1.png?nolink |}}
 +
 +==== Database Upgrades ====
 +
 +Database upgrades are done using the .NET EntityFrameworkCore migrations. When a new migration is made available typically in the source code you'll need to apply the migration. This can be done in a number of ways depending on preference and environment (development vs production). One way is to open the Package Manager Console within Visual Studio and run something like the following.
 +
 +<code>
 +PM> Update-Database -Project opensis.data -Context CRMContextMySQL
 +Build started...
 +Build succeeded.
 +Applying migration '20230216092200_AlterStaffSchoolInfoMembershipId'.
 +Done.
 +</code>
 +
 +A developer also suggested another by "hitting the API from postman or swagger" the URL https://localhost:port/{databaseName}/Common/getAllLanguageForLogin (replace the {databaseName} with the local databaseName) to automatically trigger the migration. 
 +
 +<note important>At the time of this writing I had to enabled (uncomment) the commented lines below in the file **opensis.data/Models/CRMContextMySQL.cs** to run the upgrade.
 +
 +<code csharp>
 +using System;
 +using System.Collections.Generic;
 +using System.Text;
 +using Microsoft.EntityFrameworkCore;
 +
 +namespace opensis.data.Models
 +{
 +    public class CRMContextMySQL : CRMContext
 +    {
 +        private readonly DbContextOptions? contextOptions;
 +        public CRMContextMySQL() { }
 +        public CRMContextMySQL(DbContextOptions options) : base(options)
 +        {
 +            this.contextOptions = options;
 +        }
 +        protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
 +        {
 +            if (!optionsBuilder.IsConfigured)
 +            {
 +                //var tenant = "opensisv2_ef6";
 +
 +                //string connectionString = $"server=localhost;database={tenant};user=theuser;password=thepassword";
 +                //optionsBuilder.UseMySql(connectionString, ServerVersion.AutoDetect(connectionString));
 +            }
 +
 +        }
 +    }
 +}
 +</code>
 +
 +</note>
  
 ==== Building and Running Backend ==== ==== Building and Running Backend ====
Line 131: Line 199:
 > npm install -g @angular/cli > npm install -g @angular/cli
 </code> </code>
 +
 +<note important>While the command above may install a version of Angular that will work fine in your environment, you may have better luck by installing a specific version of Angular as below.
 +
 +<code>
 +> npm install -g @angular/cli@10.0.5
 +</code>
 +</note>
  
 Browse to the ''Pacific-SIS/UI'' folder and execute the following to install all the dependencies. Browse to the ''Pacific-SIS/UI'' folder and execute the following to install all the dependencies.
Line 136: Line 211:
 <code> <code>
 > npm i > npm i
 +</code>
 +
 +==== Frontend Setup ====
 +
 +You need to configure the frontend to "talk" to the backend. You do this by editing the file 
 +''Pacific-SIS\UI\src\assets\config.json'' as shown below. Make sure the apiURLOpensis and apiURL point to the available backend.
 +
 +<code javascript>
 +{
 +  
 +    "apiURLOpensis":"https://localhost:44309/",
 +    "apiURL":"https://localhost:44309/",
 +
 +    "encryptionKey" :"encryptionkeyhere",
 +    "dataEncryptionKey" :"encryptionkeyhere"
 +    
 +}
 </code> </code>
  
 ==== Building and Running the Frontend ==== ==== Building and Running the Frontend ====
  
-This is simply a matter of starting the angular development web server and can be done using npm automation tools. Browse to the ''Pacific-SIS/UI'' folder and execute the following.+This is simply a matter of starting the angular development web server and can be done using npm automation tools. Browse to the ''Pacific-SIS/UI'' folder and execute the following. This will first build all module (Typescript to Javascript) and then run the results into the browser using another web development server.
  
 <code> <code>
Line 146: Line 238:
 </code> </code>
  
 +If all went well you should see the following login page when pointing your browser to http://localhost:4200/.
 +
 +{{ :sis-developer-manual:sis-login.jpg?nolink |}}
 +
 +
 +===== Deploying =====
 +
 +The deployment can be done in a number of ways. You can use the deployment tools in both the backend and frontend to package the files for the production server. Below explains how.
 +
 +==== Packaging the Backend ====
 +
 +Simply use the Visual Studio's publish feature. There is a publish "profile" in there that can be use as example. Two  apps need to be deployed on the backend.
 +
 +  * opensisAPI
 +  * opensis.backgroundjob
 +
 +This should look something like this.
 +
 +{{ :sis-developer-manual:pacific-sis-deploy-1.png |}}
 +
 +This will put the packaged files in specific directories on your development computer based on your publish profile.
 +
 +==== Packaging the Frontend ====
 +
 +Navigate to the ''Pacific-SIS/UI'' directory and execute the following command.
 +
 +<code>
 +> ng build
 +</code>
 +
 +This should package all the frontend files in ''Pacific-SIS/UI/dist/vex/''
  
 +==== Deploying to Production Server ====
  
 +Is a matter of preference. You could simply copy the files produced in the two previous steps and configure the Apache Server to server them. The database will need to also be deployed. One of the maintainers of the system uses Ansible to automate all of these final deployment tasks.
sis_developer_manual.1662541181.txt.gz · Last modified: 2022/09/07 08:59 by ghachey