Przejdź do treści

Podział na moduły i projekty

Definicje pojęć

Grupa projektów - to co zdefiniowaliśmy jako kwadracik na jambordzie. Docelowo każda grupa projektów może być w innej BD, więc grupy projektów nie mogą współdzielić struktur. Grupa projektów jest pojęciem technicznym.

Projekt - projekt biznesowy (neosowy), zawiera wydzieloną funkcjonalność przynależy zawsze tylko do jednej grupy projektów. Na liście referencji ma konkretną zamkniętą listę innych projektów z których może czytać dane i wywoływać funkcje API tych projektów. Projekty integracyjne mogą zależeć od projektów z różnych grup projektów.

Obszar - pojęcie licencyjne.

Moduł - pojęcie licencyjne. Moduł należy tylko do jednego obszaru. Gromadzi pewien podzbiór funkcjonalności na który sprzedajemy licencje. Każdy moduł jest zdefiniowany w jakimś projekcie. Głównie zawiera podzbiór funkcjonalności z tego projektu, w którym jest zdefiniowany.

Aplikacja Teneum składa się z grup projektów, a te z projektów. Projekt obejmuje pewną zamkniętą listę odpowiedzialności / funkcjonalności. Każdy projekt obejmuje pewne struktury danych - konkretna lista tabel i procedur SQL w bazie. Teoretycznie stare źródła (pliki c++) też powinny przynależeć do konkretnych projektów, ale nie jest to jawnie wydzielone.

Pod kątem licencjonowania (czyli sprzedaży dla klientów i związanych z tym uprawnień) funkcjonują inne pojęcia: obszaru i modułu. Moduły definiuje się w projektach neosowych, nadaje im symbole i przyznaje uprawnienia do wybranych obiektów biznesowych, a więc wybranych funkcjonalności. W szczególności uprawnienia modułowe mogą dotyczyć pojedynczych pól i elementów okien.

Jakie grupy projektów i projekty wchodzą w standard aplikacji Teneum?

Aktualnie wszystkie projekty, które wchodzą do standardu aplikacji Teneum, znajdują się na repozytorium Teneum (dawne s4) (http://git.office.sente.pl/dro/s4.git). Kod źródłowy funkcjonalności napisanych w c++ nie jest fizycznie podzielony na projekty i jedyne co zostało wydzielone, to projekt neosowy, który deklaruje wszystkie akcje tej grupy projektów we wstążce neosowej. Nowe projekty są całościowo pisane w Neosie, a więc zawierają zarówno projekt(y) neosowy z obiektami biznesowymi, jak i własne struktury danych z określonym prefiksem. Lista wszystkich projektów jest następująca (boldem zaznaczono te projekty, które mają wyodrębnione własne struktury bazodanowe):

Projekty funkcjonalne:

  • B2B - projekt zarządzania witrynami B2B (powstanie w przyszłości)

  • COMMON - tutaj znajdują się podstawowe kartoteki: klienci, dostawcy, towary, obiekty dla pluginów (GUS,VIES,VAT) oraz elementy należące do Teneum Basic, czyli słowniki (kraje, oddziały, wydziały, firmy, waluty, numeratory, consty, konfigi)

  • CRM - (powstanie w przyszłości)

  • FA - finanse i księgowość (Financial and Accounting) - na razie tylko jeden projekt a w nim tylko wstążka neosowa

  • GDPR - projekt RodoDesk

  • HR - Personel - tylko wstążka neosowa, eHRM (powstanie w przyszłości)

  • NOTUSED - nie jest to projekt z funkcjonalnością, ale worek na nieużywane struktury bazdanowe (np stary workflow)

  • PRO - Core obszaru zarządzania produkcją -

  • PPM - projekt planowania produkcji

  • RCP - rejestracja czasu pracy - tylko wstążka neosowa

  • SPM - projekt planowania zaopatrzenia (supply planning module)

  • TD - grupa projektów dotycząca sprzedaży i dystrybucji, obejmuje między innymi obsługę dokumentów sprzedaży, drukarek fiskalnych, faktur elektronicznych, zakupów, import towarów, rozliczenia i elektroniczną wymianę dokumentów handlowych - w neosie tylko wstążka. W ramach tego:

    • TD - projekt główny

    • ECOM - projekt i moduł funkcjonalny integracji z kanałami sprzedaży elektronicznej (np. IAI)

  • WFFA - Jest to projekt odpowiedzialny za rozszerzenie do aplikacji workflow umożliwiające integrację workflow z fakturami kosztowymi (wymaga projektów WORKFLOW i COMMON).

  • WMS - grupa projektów WMS. W ramach niego projekty:

    • WMS - na razie tylko wstążka neosowa

    • WMSHHAPI - projekt wystawiający API dla Android HH

  • WORKFLOW - standardowy projekt, stworzony wedle nowych standardów, który odpowiada za obieg informacji i dokumentów w firmie, jej możliwości mogą być rozszerzane za pomocą zewnętrznych projektów takich jak WFFA.

Projekty integracyjne:

  • TD2FA - moduł łączący TD i FA odpowiadający za księgowanie dokumentów (powstanie w przyszłości)

  • ECOM - bazowy projekt do integracji z kanałami sprzedaży, oraz drivery i adaptery do konkretnych kanałów

  • EDI - driver EDA do EDI (powstanie w przyszłości)

  • SPEDYTORZY - drivery EDA do spedycji (powstanie w przyszłości)

Projekty narzędziowe, technologiczne i drivery do usług zewnętrznych:

  • MAILING - klient poczty elektronicznej, moduł IMAP

  • OCR - drivery EDA do usług OCR, np Skanuj.To

  • WHITELIST - projekt narzędziowy do białej listy

Projekty technologiczne:

  • SYSTEM - Neos Expert i narzędzia dodatkowe Neosa

  • EXPORTER - ???

  • IMPORTER - mechanizmy importu danych z excela wraz z mapowaniem kolumn, itp

  • SCHEDULER - projekt schedulera

Raporty i analizy (Reports and Analysis). Grupa projektów składa się z następujących projektów neosowych:

  • RA - jest to projekt odpowiadający za obiekty które są wykorzystywane do prezentacji raportów, analiz i dashboard'ów. Dobrym przykładem jest dashboard, który widzimy po zalogowaniu do aplikacji Workflow. Jest to zbiór analiz z różnych obszarów przedstawiony na jednej formie.

  • RACOMMON - elementy wspólne dla raportów i analiz z różnych obszarów (np wspólne słowniki do parametrów raportów)

  • RAFA - Są to raporty i analizy dla obszaru księgowość

  • RAHR - Są to raporty i analizy dla obszaru personel

  • RAPRO - Są to raporty i analizy dla obszaru produkcja

  • RATD - Są to raporty i analizy dla obszaru sprzedaż i dystrybucja

Zależności między projektami

W tym dokumencie znajduje się rysunek obrazujący zależnosci między projektami wchodzącymi w skład aplikacji Teneum.

Standardowe projekty neosowe posiadają pewną hierarchię zależności / referencji (oznaczoną strzałką), która nie powinna być naruszona. Hierarchia sprowadza się do następujących zasad:

  1. Pluginy i projekty narzędziowe (np WHITELIST, MAILING) nie powinny mieć na liście zależności do żadnych innych projektów, gdyż to każdy inny projekt może używać projektu narzędziowego, a więc mieć do niego referencje. Projekty takie powinny się kompilować i działać nawet samodzielnie bez obecności, żadnego innego projektu.

  2. WORKFLOW nie może zależeć od niczego, gdyż każdy inny projekt może implementować rozszerzenie workflow, a więc będzie miał referencje do WORKFLOW

  3. Projekty funkcjonalne mogą mieć zależności do projektów ogólnego przeznaczenia, takich jak MDM, WORKFLOW, a także pluginów, narzędzi i projektów technologicznych(np. WHITELIST)

  4. Projekty technologiczne (SCHEDULER, SYSTEM) powinny być niezwiązane z żadnym innym projektem.

  5. Projekty SPM, PRO, WMS mają zależności na TD i MDM (COMMON).

  6. Projekty przekrojowe i integracyjne powinny mieć zależności na te projekty, z których korzystają lub które integrują. Np projekt pozwalający księgować dokumenty handlowe z projektu TD w projekcie księgowym FA, powinien mieć na liście zależności zarówno TD jak i FA. Projekty TD i FA nie muszą wiedzieć o sobie nawzajem.

  7. W obszarze raportów i analiz, projekty dziedzinowe (RAFA, RAHR) mogą mieć referencje na elementy wspólne (RACOMMON), natomiast główny projekt gromadzący dashboardy i analizy standardowe (RA) ma na liście referencji wszystkie projekty dziedzinowe, workflow oraz projekty funkcjonalne, gdyż gromadzi analizy z całego systemu.

Automatyczne usuwanie zależności (referencji) między projektami w formacie 6.0 w Visual Studio Code

W projektach w formacie 6.0 należy ręcznie usuwać referencje do projektów poprzez usunięcie dyrektywy using wskazującej na projekt, do którego była referencja w pliku .cs.

Istnieją też sposoby, by automatycznie to robić przy pomocy Visual Studio Code. Poniżej zamieszczone zostały 3 metody aby to wykonać.

Metoda 1: Korzystanie z Roslynator

Roslynator to popularne rozszerzenie do Visual Studio Code, które oferuje wiele funkcji do refaktoryzacji i analizy kodu, w tym usuwanie nieużywanych using.

1. Zainstaluj Roslynator:
  • Otwórz Visual Studio Code.
  • Przejdź do zakładki Extensions (Ctrl+Shift+X).
  • Wyszukaj "Roslynator" i zainstaluj rozszerzenie autorstwa Josef Pihrt.
2. Skonfiguruj Roslynator:
  • Po zainstalowaniu rozszerzenia, przejdź do ustawień rozszerzenia (klikając na ikonę zębatki obok Roslynator i wybierając "Extension Settings").
  • Znajdź i zaznacz opcję "Remove and sort usings".
3. Uruchom refaktoryzację:
  • Otwórz terminal w Visual Studio Code (Ctrl+`).
  • Przejdź do katalogu głównego projektu.
  • Uruchom polecenie: dotnet format --fix-style error aby automatycznie usunąć nieużywane dyrektywy using w całym projekcie.

Metoda 2: Korzystanie z wbudowanej funkcji .NET SDK

Od wersji .NET Core 3.0, .NET SDK zawiera narzędzie dotnet format, które może być używane do formatowania kodu, w tym usuwania nieużywanych using.

1. Zainstaluj narzędzie dotnet format:
  • Upewnij się, że masz zainstalowane najnowsze SDK .NET. Możesz zainstalować narzędzie, uruchamiając polecenie: dotnet tool install -g dotnet-format
2. Uruchom narzędzie dotnet format:
  • Przejdź do katalogu głównego projektu w terminalu Visual Studio Code.
  • Uruchom polecenie: dotnet format --fix-style error To polecenie usunie nieużywane dyrektywy using oraz przeprowadzi inne poprawki stylu.

Metoda 3: Manualne usuwanie dyrektyw using

Visual Studio Code oferuje również opcję ręcznego usuwania nieużywanych dyrektyw using w edytorze. 1. Otwórz plik C#. 2. Kliknij prawym przyciskiem myszy w dowolnym miejscu w edytorze kodu. 3. Wybierz opcję Organize Usings i następnie Remove Unnecessary Usings.

W jaki sposób dodać nowy projekt lub zmodyfikować strukturę projektów?

Nie można samodzielnie zmieniać struktury projektów Teneum. Za jej zmianę odpowiada rola głównego architekta Teneum. Rola ta nie ingeruje w wewnętrzną strukturę poszczególnych projektów, ale dba o podział odpowiedzialności i funkcjonalności między projektami oraz dopuszczalne zależności między nimi, w tym wygląd i działanie fasad. Obecnie tą rolę pełni Paweł Michoń.

Gdzie umieszczać nowe projekty, które mają być emitowane jako standard?

Nowe projekty powinny być umieszczane w grupach do których logicznie przynależą, np. projekt WFFA powinien się znaleźć w folderze WFFA. Projekt neosowy powinien być umieszczony w podfolderze WFFA\Neos.Projects. Jeśli powstaną do tego obszaru osobne pluginy w Visual Studio, to ich źródła powinny się znaleźć w folderze WFFA\plugins.

Struktury bazodanowe przechowujemy w podfolderze WFFA\dbscripts, ale tylko wtedy, gdy struktury są jawnie wydzielone pewnym prefiksem lub listą prefiksów i zostały one zapisane w pliku shfilter.txt. Obecnie szereg projektów na gicie ma już wyodrębnione struktury danych w w/w pliku. Jeśli są to tzw. "stare" moduły, których struktury w bazie nie miały prefiksów, to przechowujemy je we wspólnym folderze dbscripts.