This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
ra:development [2018/08/23 14:43] koubel [Database] |
ra:development [2021/12/11 18:13] (current) koubel [UI test] |
||
|---|---|---|---|
| Line 46: | Line 46: | ||
| Changes in database structure are made through update scripts. These are stored in db tables 'upgrades' tables e.g. 'DatabaseUpgrade' for core tables, KADatabaseUpgrade for database upgrades for KA database modules etc. These tables store information about every upgrade script and when it was called. When new database deployement is started, only these update scripts which aren't in these 'upgrades' tables are processed. | Changes in database structure are made through update scripts. These are stored in db tables 'upgrades' tables e.g. 'DatabaseUpgrade' for core tables, KADatabaseUpgrade for database upgrades for KA database modules etc. These tables store information about every upgrade script and when it was called. When new database deployement is started, only these update scripts which aren't in these 'upgrades' tables are processed. | ||
| + | |||
| + | Be aware, that in some cases e.g. for new customer, when customer needs some new modules e.g. all particular update scripts can be applied. So when we remove some column it's necessary to check if this one isn't used in some old update scripts. | ||
| Some customers has very special database setup, see Customers paragraph. | Some customers has very special database setup, see Customers paragraph. | ||
| - | Online Data | + | OnlineData, OnlineDataProcessed |
| + | |||
| + | OnlineData and OnlineDataProcessed are special tables for data processing. Important column is ROM. It defines observed "unit" which can send online data - table dbUnit. | ||
| + | |||
| + | Showing online data processed for particular vehicle - ROM. | ||
| + | |||
| + | select * from OnlineDataProcessed | ||
| + | where ROM = '352094087747884' and date > '2018-10-01' and date < '2018-10-10' | ||
| + | |||
| + | It's necessary to specify minimal date interval, because table is huge and queries can timeout. | ||
| + | |||
| + | Important table, columns: | ||
| + | |||
| + | * OnlineDataProcessed.ID_ONLINE_DATA_ERROR_TYPE must be not NULL | ||
| + | * OnlineDataProcessed.ID_VEHICLE must be filled. If ins't filled, it means that vehicle was imported later then first online data was arrived. | ||
| + | * DbUnit - it's table for ROMs, it defines which OnlineDataSource is used for particular ROM. | ||
| + | * VehicleUnit - relation table between unit and vehicle. | ||
| + | |||
| + | Copying data from one onlinedata database to another, see more information on [[http://10.0.2.27/doku.php?id=protank_dynamics:pd_databaze#kopirovani_online_dat|raltra wiki]] | ||
| There is special fetching process in code. Sometimes it's necessary to add columns into online data database from the OnlineDataColumns table, it's processed via stored procedures | There is special fetching process in code. Sometimes it's necessary to add columns into online data database from the OnlineDataColumns table, it's processed via stored procedures | ||
| Line 60: | Line 81: | ||
| object and tables | object and tables | ||
| - | - daily report - stazka - DDDailyReport in db | + | * daily report - stazka - DDDailyReport in db |
| - | - containers - nádoby - PLAContainersView in DB, many tables, PLAContainersView.cs in Application | + | * containers - nádoby - PLAContainersView in DB, many tables, PLAContainersView.cs in Application |
| - | - defects - závady | + | * defects - závady |
| + | |||
| ====== Customers ====== | ====== Customers ====== | ||
| Line 78: | Line 100: | ||
| features | features | ||
| - | - add feature into ''Application/PSASWeb/FeaturesAll.ftr'', will be visible for all applications | + | * add feature into ''Application/PSASWeb/FeaturesAll.ftr'', will be visible for all applications |
| - | - add feature into particular project, e.g. ''Application/Configuration/isud/features.ftr'' | + | * add feature into particular project, e.g. ''Application/Configuration/isud/features.ftr'' |
| + | |||
| + | ====== Builds ====== | ||
| + | |||
| + | Builds are on VSTS in tab "Builds and releases". Error in builds are mostly linked into task with "link" icon. | ||
| + | |||
| + | Deploy to particular customer: | ||
| + | |||
| + | * Go to VSTS tab "Builds and releases" -> "Builds" -> "Build Definitions" -> "PD1 Build Autodeployable" (click on this) | ||
| + | * Click on button "Queue new build" -> dialog -> fill your branch and fill customer e.g. avecz | ||
| + | * It will start process for building new package e.g. release for particular branch | ||
| + | * Wait some time, release will be created | ||
| + | * Go to "releases" page, you will se e.g. "Release-365" for our branch. | ||
| + | * Click on this release, you will see list of environments, click on "Action" column - "..." for particular row for customer/environment for deploy. Deployment process will be started after some time. You can se progress on "Logs" tab. Deployment process are serialized in queue. Result of deployment is visible after some time on environment tab after some time. | ||
| + | |||
| + | ====== Reports ====== | ||
| + | |||
| + | Reports are based on DevExpress reports with extension in Visual Studio. Reports when you click on report file e.g. ''ReportUserRights.cs''. Dialog designer will be opened. Set No to question about converting binding to expression. All report components, including data bindings, detail bond e.g. are pulled from the Toolbox Palet in designer into main report. | ||
| + | |||
| + | Each time, we make some changes in report project, doesn't matter if in code or design. It's necessary to rebuild the particular report project, because each report is in own ''dll''. | ||
| + | |||
| + | Data binding | ||
| + | |||
| + | Each report has own data connection. Mostly it's via dynamic binding. Opens the Visual Studio main menu XtraReports -> Report Explorer. There is e.g. Components -> binding1. Click right on binding1 and select Properties. You will see dynamic binding with BindingSource class, where property binding1.DataSource is particular class. Correct binding must be edited directly in code with line e.g. ''%%this.ManualSource.DataSource = typeof(ReportCreator.DataRow);%%''. And then particular project must be rebuild. | ||
| + | When the class instance of DataRow is filled in code and in Report class result is assigned via call e.g. %%DataSource = ReportCreator.Create()%%, then the data will be dynamically transfered into report. This is mostly via some report events, which are accessible via bolt icon in Properties tab. | ||
| + | |||
| + | Some reports has data binding via designed query, some XSD files. Mostly these will be replaced with dynamic data via %%ReportCreator%% class as ORM usage inside it. | ||
| + | |||
| + | Some reports are sets as master detail e.g. %%ReportUserRights%%. These reports are bound to the class, which is master record and has some detail records. Such report has to have Detail Bond component and %%DetailReport%% and some %%Details%%, which are inserted into detail report via click right to DetailReport and select "Insert Detail Report" -> detail class name. | ||
| + | |||
| + | * DevExpress report designer [[https://documentation.devexpress.com/XtraReports/2590/Getting-Started-with-DevExpress-Reporting/First-Look-at-the-Report-Designer|tutorial]] | ||
| + | * DevExpress banded report for e.g. master detail [[https://documentation.devexpress.com/XtraReports/2587/Detailed-Guide-to-DevExpress-Reporting/Introduction-to-Banded-Reports#UnderstandingReportBands|documentation]] | ||
| + | |||
| + | ====== Service processing ====== | ||
| + | |||
| + | * Copy configuration part of ''%%customer-dev/Service/PSAS.LiveDataProcessor.Service.exe.config%%'' into ''LiveServiceProcessorService/App.Config/'' | ||
| + | * In ServiceThreadTable search for thread name - column Name. | ||
| + | * Set the breakpoint into some LiveDataProcess.ServiceNameThread class, somewhere into %do_tick% method. | ||
| + | * Run LiveServiceProcessor application. | ||
| + | * In dialog, try to find thread by name a run it. | ||
| + | * Wait for breakpoint when is reached. | ||
| + | |||
| + | ====== Integration Tests ====== | ||
| + | |||
| + | Integration (or ServiceTest) are grouped together in projects in PSAS_ServiceTest solution e.g ServiceTest/LiveDataProcessorPHM.Tests. | ||
| + | Test runner can run tests parallel from different groups/projects. It means that only one test from one particular project can run once. It's used because each testing project has own database for tests, so only one test can use these database in particular time, it prevents the race conditions, locking database etc. | ||
| + | |||
| + | ====== UI test ====== | ||
| + | |||
| + | These are run on //tfs server build server 4//. Run test manually | ||
| + | |||
| + | * make build on Azure dev | ||
| + | * deploy on particular testing environment | ||
| + | * run tests manually with command | ||
| + | |||
| + | <code> | ||
| + | C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "c:\agent_interactive\_work\r1\a\PD1 Build Autodeployable\PD1 UI Tests\Debug\net47\GlobalTests.dll" /TestCaseFilter:"TestCategory=APL_LB&TestCategory=OpensProperlyModules&TestCategory!=Reports" /logger:"trx" /TestAdapterPath:"c:\agent_interactive\_work\r1\a\PD1 Build Autodeployable\PD1 UI Tests\" | ||
| + | </code> | ||
| + | |||
| + | Important part for run only particular tests. | ||
| + | <code> | ||
| + | /TestCaseFilter:"TestCategory=APL_LB&TestCategory=OpensProperlyModules&TestCategory!=Reports" | ||
| + | </code> | ||
| + | |||
| + | These are test for LogBook which opens page properly. | ||
| + | But there can be problem with deployed master - it triggers the test automatically. | ||
| + | |||
| + | ====== Development notices ====== | ||
| + | |||
| + | Jo a co jsi tam psal s tím že jsem na Tahiti a vyplňování stazky. To jsem opravdu kokot, protože vyplňuju svoz nějaké popelnici co je v Praze z počítače na Tahati, takže je jasné že bude problém. | ||
| + | |||
| + | Browsery vždycky zobrazují lokální čas podle nastavení celého počítače a jakmile by se do tohohle nativního chování začalo hrabat, tak je zaděláno na obrovské problémy naprosto všude kde pracuje v browseru s datumem a to bychom si tedy už fakt zavařili. Prostě si změním timezone v počítači na Prahu. | ||
| + | |||
| + | To už tedy posílat tu timezone klienta a ať si ty timeshifty dělá server při odesílání a ukládání dat a klienti pak uvidí to, co se děje někde v timezone dané někde nějakým nastavením na backendu pro zákazníka. Ale určitě neřešit na klientovi. | ||
| + | |||
| + | Ono do důsledku se klidně může lišit timezone jednotlivých lokalit jednoho zákazníka, nebo dokonce jednotlivých fyzických objektů - míst svozů, nádob, tras atd atd., např. v tom Maďarsku, Polsku atd atd. Takže každý "fyzický objekt" by měl mít i někde v db nastavenu timezone ale řešit by to měl server na základě timezone, co dostane od klienta. | ||
| + | |||
| + | ---- | ||
| - | | ||