lint(standard): corrections completes mode standard
- Em dashes: 1712 remplaces par tirets simples (86 fichiers + _index.md, en-tete section Limagrain conserve) - Checklists: 24 '- [ ]' -> '- ☐' (3 pages operations, plus de todos Obsidian) - Ancres: 33 reparees (slugs GitHub + ancres HTML <a id> reconnues), 1 reciblee (manuel de reten) - related: tenseflow -> tense-flow, pie -> mechanical-elements, group.md retire (doublon shipping) - Registre: compteur global 122 -> 131 pages - Rapport racine _lint_report.md mis a jour (scan v2 + re-scan final: 0 anomalie) - Aucun fichier limagrain/ modifie (cloisonnement)
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: "AGV Module — Installation Guide"
|
||||
title: "AGV Module - Installation Guide"
|
||||
type: operation
|
||||
sources:
|
||||
- sources/archives/Documentation Module AGV.md
|
||||
@@ -10,11 +10,11 @@ related:
|
||||
last_compiled: "2026-05-15"
|
||||
---
|
||||
|
||||
# AGV Module — Installation Guide
|
||||
# AGV Module - Installation Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide covers the end-to-end installation of the AGV module for Easy WMS. The module relies on a PostgreSQL intermediary database, an ODBC driver, an Oracle DBLink (dg4odbc), the Gateway AGV Windows service, and the AGV application package deployed into Easy WMS. For the functional description of the module, see [AGV — Automated Guided Vehicles](../modules/agv.md).
|
||||
This guide covers the end-to-end installation of the AGV module for Easy WMS. The module relies on a PostgreSQL intermediary database, an ODBC driver, an Oracle DBLink (dg4odbc), the Gateway AGV Windows service, and the AGV application package deployed into Easy WMS. For the functional description of the module, see [AGV - Automated Guided Vehicles](../modules/agv.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -35,7 +35,7 @@ dir C:\Mecalux\Motor\oracle\Product\
|
||||
|
||||
> Throughout this guide, `[ORACLE_HOME]` refers to the full path, e.g. `C:\Mecalux\Motor\oracle\Product\19.27.0.0\dbhome_1`. **Always replace** `[ORACLE_HOME]` **with your actual path** - leaving the placeholder is a frequent cause of failure.
|
||||
|
||||
## Step 1 — Install PostgreSQL
|
||||
## Step 1 - Install PostgreSQL
|
||||
|
||||
Download PostgreSQL >= 14 from the official EDB site and install with default options. Note the listening port - this is critical: PostgreSQL <= 17 uses port **5432**, while **PostgreSQL 18+ defaults to port 5433**.
|
||||
|
||||
@@ -63,13 +63,13 @@ netsh advfirewall firewall add rule name="PostgreSQL AGV" dir=in action=allow pr
|
||||
|
||||
Adjust the port number if using PostgreSQL 18+ (5433).
|
||||
|
||||
## Step 2 — Install the PostgreSQL ODBC driver
|
||||
## Step 2 - Install the PostgreSQL ODBC driver
|
||||
|
||||
> The download link in the official MSS documentation is dead. Go to the PostgreSQL ODBC releases page and download the latest `psqlodbc_x64.msi` (not the wrapper setup.exe).
|
||||
|
||||
Install the MSI with default options.
|
||||
|
||||
## Step 3 — Configure the System DSN (64-bit ODBC)
|
||||
## Step 3 - Configure the System DSN (64-bit ODBC)
|
||||
|
||||
Open **ODBC Data Sources (64-bit)** (`C:\Windows\System32\odbcad32.exe`), go to the **System DSN** tab (not User DSN), click **Add**, and select the **PostgreSQL Unicode(x64)** driver.
|
||||
|
||||
@@ -84,11 +84,11 @@ Open **ODBC Data Sources (64-bit)** (`C:\Windows\System32\odbcad32.exe`), go to
|
||||
|
||||
In the **Datasource** tab, **uncheck "Bools as Char"**. Click **Test** to verify the connection.
|
||||
|
||||
> **Critical — DSN name case**: the name `PostgreSQL35W` (capital P and W) is used verbatim in **5 different Oracle configuration files**. The case must be **absolutely consistent** across all files. Using `POSTGRESQL35W` (all caps) or `postgresql35w` (all lowercase) will cause a silent dg4odbc failure. See the Troubleshooting section for details.
|
||||
> **Critical - DSN name case**: the name `PostgreSQL35W` (capital P and W) is used verbatim in **5 different Oracle configuration files**. The case must be **absolutely consistent** across all files. Using `POSTGRESQL35W` (all caps) or `postgresql35w` (all lowercase) will cause a silent dg4odbc failure. See the Troubleshooting section for details.
|
||||
|
||||
## Step 4 — Install and start the Gateway AGV
|
||||
## Step 4 - Install and start the Gateway AGV
|
||||
|
||||
### 4.1 — Verify the configuration file
|
||||
### 4.1 - Verify the configuration file
|
||||
|
||||
The config file is located at `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\`. The XML file must contain exactly **one** `<AGVConfig>` section. If it contains two (e.g., for two stations), the provider will not initialize and the service will crash with `Migration DataBase Provider No Initialized`.
|
||||
|
||||
@@ -121,7 +121,7 @@ Verify that the connection string points to the correct PostgreSQL database:
|
||||
|
||||
> If using **PostgreSQL 18+** (port 5433), add the port explicitly: `Host=localhost;Port=5433;user id=mecaluxAGV;...`
|
||||
|
||||
### 4.2 — First startup (table creation)
|
||||
### 4.2 - First startup (table creation)
|
||||
|
||||
Start the Gateway AGV service (`services.msc` > EasyWMS GatewayAGV). Check the log at `C:\ProgramData\Mecalux\EasyWMS GatewayAGV 2015\Logs\AllLog.log` for successful migration lines:
|
||||
|
||||
@@ -132,15 +132,15 @@ Start the Gateway AGV service (`services.msc` > EasyWMS GatewayAGV). Check the l
|
||||
|
||||
If these lines appear, the tables were created successfully. Errors after these lines are normal (the Gateway tries to communicate with the fleet manager which is not yet connected). **Stop the service** after verification.
|
||||
|
||||
### 4.3 — Verify created tables
|
||||
### 4.3 - Verify created tables
|
||||
|
||||
In PgAdmin4, under the AGV database > Schemas > public > Tables, there should be 7 tables: `agv_age`, `agv_ags`, `agv_eag`, `agv_inputqueue`, `agv_maintenance`, `agv_outputqueue`, `std_migrationinfo`. And 6 sequences: `agv_age_id_seq`, `agv_ags_id_seq`, `agv_eag_id_seq`, `agv_inputqueue_id_seq`, `agv_maintenance_id_seq`, `agv_outputqueue_id_seq`.
|
||||
|
||||
### 4.4 — Execute PostgreSQL scripts
|
||||
### 4.4 - Execute PostgreSQL scripts
|
||||
|
||||
Open the Query Tool in PgAdmin4 on the AGV database and execute:
|
||||
|
||||
**Script 1 — Notification function** (publishes an event on every row change):
|
||||
**Script 1 - Notification function** (publishes an event on every row change):
|
||||
|
||||
```sql
|
||||
CREATE FUNCTION public."NotifyOnDataChange"()
|
||||
@@ -165,7 +165,7 @@ END
|
||||
$BODY$;
|
||||
```
|
||||
|
||||
**Script 2 — Trigger on the inputqueue table**:
|
||||
**Script 2 - Trigger on the inputqueue table**:
|
||||
|
||||
```sql
|
||||
CREATE TRIGGER "OnDataChange"
|
||||
@@ -174,19 +174,19 @@ FOR EACH ROW
|
||||
EXECUTE PROCEDURE public."NotifyOnDataChange"();
|
||||
```
|
||||
|
||||
## Step 5 — Configure the external PostgreSQL user
|
||||
## Step 5 - Configure the external PostgreSQL user
|
||||
|
||||
This user will be used by the Oracle DBLink to access the AGV tables from the WMS.
|
||||
|
||||
### 5.1 — Create the user
|
||||
### 5.1 - Create the user
|
||||
|
||||
In PgAdmin4: create a login role `externalAGV` with a password and login privilege.
|
||||
|
||||
### 5.2 — Grant CONNECT on the database
|
||||
### 5.2 - Grant CONNECT on the database
|
||||
|
||||
In the AGV database properties > Security tab, add `externalAGV` with the **CONNECT** privilege.
|
||||
|
||||
### 5.3 — Grant permissions on tables and sequences
|
||||
### 5.3 - Grant permissions on tables and sequences
|
||||
|
||||
**Quick option (dev environment)**:
|
||||
|
||||
@@ -211,11 +211,11 @@ GRANT ALL ON agv_ags_id_seq TO "externalAGV";
|
||||
GRANT ALL ON agv_inputqueue_id_seq TO "externalAGV";
|
||||
```
|
||||
|
||||
## Step 6 — Configure the Oracle DBLink to PostgreSQL
|
||||
## Step 6 - Configure the Oracle DBLink to PostgreSQL
|
||||
|
||||
This is the most delicate step. Oracle uses the **dg4odbc** component (Database Gateway for ODBC) to connect to PostgreSQL via the ODBC DSN created in Step 3. The configuration touches 3 Oracle files and requires a Listener restart.
|
||||
|
||||
### 6.1 — Edit tnsnames.ora
|
||||
### 6.1 - Edit tnsnames.ora
|
||||
|
||||
File: `[ORACLE_HOME]\network\admin\tnsnames.ora`
|
||||
|
||||
@@ -234,7 +234,7 @@ Leave a blank line between the previous entry and this one. `(HS=OK)` is mandato
|
||||
|
||||
> **Common error**: if the identifier is indented (space or tab before `PostgreSQL35W =`), Oracle returns `ORA-12154: TNS:could not resolve the connect identifier specified`. This is a subtle trap because the rest of the file works fine with indentation.
|
||||
|
||||
### 6.2 — Edit listener.ora
|
||||
### 6.2 - Edit listener.ora
|
||||
|
||||
File: `[ORACLE_HOME]\network\admin\listener.ora`
|
||||
|
||||
@@ -250,7 +250,7 @@ Add a `SID_DESC` block in the existing `SID_LIST_LISTENER` section:
|
||||
|
||||
> **Critical**: the `ORACLE_HOME` path in this block must be the **real, complete path** of your Oracle installation. Never leave a placeholder like `[VERSION]` - this causes `TNS-12518` / `ORA-28545` errors. The listener starts without error and the SID appears in `lsnrctl status`, making the problem hard to diagnose. **Verify** that the `ORACLE_HOME` in the PostgreSQL35W block is **identical** to the other `SID_DESC` blocks in the file.
|
||||
|
||||
### 6.3 — Create initPostgreSQL35W.ora
|
||||
### 6.3 - Create initPostgreSQL35W.ora
|
||||
|
||||
Go to `[ORACLE_HOME]\hs\admin\`, duplicate the file `initdg4odbc.ora`, rename the copy to `initPostgreSQL35W.ora` (name must match the SID_NAME exactly, case-sensitive), and replace all content with:
|
||||
|
||||
@@ -261,7 +261,7 @@ HS_FDS_TRACE_LEVEL = 0
|
||||
|
||||
Do not leave the template lines from the original file. For debugging, temporarily set `HS_FDS_TRACE_LEVEL = 4` for detailed dg4odbc traces. Reset to 0 after diagnosis.
|
||||
|
||||
### 6.4 — Restart the Oracle Listener
|
||||
### 6.4 - Restart the Oracle Listener
|
||||
|
||||
```
|
||||
lsnrctl stop
|
||||
@@ -276,7 +276,7 @@ lsnrctl status
|
||||
|
||||
Expected output: `Service "PostgreSQL35W" has 1 instance(s). Instance "PostgreSQL35W", status UNKNOWN, has 1 handler(s) for this service...` The UNKNOWN status is normal for a Heterogeneous Service - the process is launched on demand.
|
||||
|
||||
### 6.5 — Grant CREATE DATABASE LINK to db_read
|
||||
### 6.5 - Grant CREATE DATABASE LINK to db_read
|
||||
|
||||
Connect as **sysdba** and grant:
|
||||
|
||||
@@ -286,7 +286,7 @@ GRANT CREATE DATABASE LINK TO db_read;
|
||||
|
||||
> The target user is **db_read** (the Easy WMS read model schema). The database link and synonyms must be owned by db_read. Do not create the link under SYS - it will not be visible from db_read.
|
||||
|
||||
### 6.6 — Create the Database Link
|
||||
### 6.6 - Create the Database Link
|
||||
|
||||
Connect as **db_read** (not sysdba):
|
||||
|
||||
@@ -298,7 +298,7 @@ CREATE DATABASE LINK AGV
|
||||
|
||||
> **Double quotes** around the user and password are **mandatory**. Oracle converts identifiers to uppercase by default, but PostgreSQL is case-sensitive. Without quotes, Oracle sends `EXTERNALAGV` instead of `externalAGV` and authentication fails.
|
||||
|
||||
### 6.7 — Test the DBLink
|
||||
### 6.7 - Test the DBLink
|
||||
|
||||
```sql
|
||||
SELECT * FROM "agv_inputqueue"@AGV;
|
||||
@@ -306,7 +306,7 @@ SELECT * FROM "agv_inputqueue"@AGV;
|
||||
|
||||
If the query returns `no rows selected`, the link works. The tables are simply empty at this stage.
|
||||
|
||||
### 6.8 — Create Oracle synonyms
|
||||
### 6.8 - Create Oracle synonyms
|
||||
|
||||
Still connected as **db_read**:
|
||||
|
||||
@@ -322,9 +322,9 @@ CREATE SYNONYM agv_outputqueue FOR "agv_outputqueue"@AGV;
|
||||
|
||||
Verify all synonyms: `SELECT * FROM agv_inputqueue;` (repeat for each). All queries must pass without error (`no rows selected` is expected).
|
||||
|
||||
## Step 7 — Install the AGV module in Easy WMS
|
||||
## Step 7 - Install the AGV module in Easy WMS
|
||||
|
||||
### 7.1 — Modify response.xml
|
||||
### 7.1 - Modify response.xml
|
||||
|
||||
Add the AGV entries in the deployment `response.xml`:
|
||||
|
||||
@@ -340,11 +340,11 @@ Add the AGV entries in the deployment `response.xml`:
|
||||
</Modules>
|
||||
```
|
||||
|
||||
### 7.2 — Run the deploy
|
||||
### 7.2 - Run the deploy
|
||||
|
||||
Execute the deploy using **option 16 — Install application**.
|
||||
Execute the deploy using **option 16 - Install application**.
|
||||
|
||||
### 7.3 — Restart the Gateway AGV
|
||||
### 7.3 - Restart the Gateway AGV
|
||||
|
||||
After the deploy completes, restart the Gateway AGV service in `services.msc`.
|
||||
|
||||
@@ -413,5 +413,5 @@ If this test passes but the Oracle DBLink fails, the problem is in the dg4odbc c
|
||||
|
||||
## Related
|
||||
|
||||
- [AGV — Automated Guided Vehicles](../modules/agv.md) — Functional documentation: architecture, protocol, monitoring, errors
|
||||
- [Stations](../concepts/stations.md) — Station types including AGV (type 65), equipment groups, routes
|
||||
- [AGV - Automated Guided Vehicles](../modules/agv.md) - Functional documentation: architecture, protocol, monitoring, errors
|
||||
- [Stations](../concepts/stations.md) - Station types including AGV (type 65), equipment groups, routes
|
||||
|
||||
@@ -19,11 +19,11 @@ last_compiled: "2026-04-17"
|
||||
|
||||
Procédure interne Mecalux EasyWMS France pour la **revue d'une tâche de développement custom** avant intégration sur `develop`. La revue se fait sur **trois axes** complémentaires, généralement par des reviewers distincts (parfois cumulés) :
|
||||
|
||||
1. **Revue Code** — qualité technique, conventions de nommage, identification du custom (`CST_`), gestion des `null`, erreurs classiques sur le modèle Outbound/Kit
|
||||
2. **Revue Fonctionnel** — exécution des cas de test Jira, comportement des touches `Enter` / `Échap` sur les dialogues
|
||||
3. **Revue Documentation** — Jira commentée, présence des éléments dans la branche Git, mise à jour du **reten** (manuel de retention en Markdown — cf. [development-methodology](development-methodology.md))
|
||||
1. **Revue Code** - qualité technique, conventions de nommage, identification du custom (`CST_`), gestion des `null`, erreurs classiques sur le modèle Outbound/Kit
|
||||
2. **Revue Fonctionnel** - exécution des cas de test Jira, comportement des touches `Enter` / `Échap` sur les dialogues
|
||||
3. **Revue Documentation** - Jira commentée, présence des éléments dans la branche Git, mise à jour du **reten** (manuel de retention en Markdown - cf. [development-methodology](development-methodology.md))
|
||||
|
||||
Sources : Confluence EasyWMS France — *Revue - Code* (v10, 08/01/2026), *Revue - Fonctionnel* (v2, 27/02/2024), *Revue - Documentation* (v3, 04/03/2024).
|
||||
Sources : Confluence EasyWMS France - *Revue - Code* (v10, 08/01/2026), *Revue - Fonctionnel* (v2, 27/02/2024), *Revue - Documentation* (v3, 04/03/2024).
|
||||
|
||||
> Référentiel global Mecalux Espagne : [code review checklist](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/code_review/index.md), [nomenclature](https://msscc.mecalux.com/documentation/Development/master/ES/map_development_concepts/nomenclature/index.md), [null management best practices](https://msscc.mecalux.com/documentation/Development/master/ES/map_application_development/null_management_best_practices/index.md).
|
||||
|
||||
@@ -56,7 +56,7 @@ Si le projet utilise les **kits sans assemblage** (cf. [kits](../concepts/kits.m
|
||||
|
||||
> ⚠️ Sur les requêtes en **writing**, l'attribut `ProductConversion` d'une ligne d'ordre de sortie peut être `null`.
|
||||
|
||||
Cas : la commande demande un **support spécifique** sans article — on a alors le **code support renseigné mais pas l'article**, donc pas de conversion produit.
|
||||
Cas : la commande demande un **support spécifique** sans article - on a alors le **code support renseigné mais pas l'article**, donc pas de conversion produit.
|
||||
|
||||
### 1.4 Identification du custom dans le code
|
||||
|
||||
@@ -113,7 +113,7 @@ Chaque nouvel élément ou élément modifié doit être **préfixé `CST_`**. T
|
||||
Particulièrement : **`FirstOrDefault()`** doit être sécurisé.
|
||||
|
||||
```csharp
|
||||
// ❌ Dangereux — exception si aucun ordre n'existe
|
||||
// ❌ Dangereux - exception si aucun ordre n'existe
|
||||
Context.OutboundOrders.FirstOrDefault(s => s.Code == outboundOrderCode).OutboundLines
|
||||
|
||||
// ✅ Sécurisé
|
||||
@@ -156,7 +156,7 @@ Vérifier la **présence des éléments modifiés** dans la branche Git concern
|
||||
|
||||
> Vérification utile : l'**historique des commits** Git du développeur pour s'assurer qu'il n'a **pas inclus de modifications hors périmètre** de sa tâche. Ce cas survient quand le dev a été réalisé **avec une custom app qui n'était pas au même "niveau"** que la branche sur laquelle il l'exporte (typiquement : création de la branche **après** import de la custom app dans le Builder, alors que d'autres commits ont eu lieu entre temps).
|
||||
>
|
||||
> Cf. [custom-application-management](custom-application-management.md) — règles d'import/export pour éviter ce cas.
|
||||
> Cf. [custom-application-management](custom-application-management.md) - règles d'import/export pour éviter ce cas.
|
||||
|
||||
### 3.3 Reten
|
||||
|
||||
@@ -166,9 +166,9 @@ Vérifier que la description de la tâche est **présente dans le reten** avec *
|
||||
|---|---|
|
||||
| Le custom **modifie le comportement d'un process** | Décrit dans les **chapitres de process** (Entries, Exits, Picking, etc.) avec **description fonctionnelle, technique et éléments custom** |
|
||||
| Le custom **ne modifie pas le comportement d'un process** | Présent dans les **tableaux d'éléments custom en fin de reten**, avec description de la modification |
|
||||
| Des **custom attributes** ont été utilisés | Listés dans la partie **"1.2 General custom elements"** du reten — et **idéalement aussi dans la tâche Jira liée** au custom quand il s'agit d'un process custom |
|
||||
| Des **custom attributes** ont été utilisés | Listés dans la partie **"1.2 General custom elements"** du reten - et **idéalement aussi dans la tâche Jira liée** au custom quand il s'agit d'un process custom |
|
||||
|
||||
> Le reten est un manuel de retention en **Markdown**, géré dans le repo Git du projet (cf. [development-methodology](development-methodology.md#manuel-de-reten)).
|
||||
> Le reten est un manuel de retention en **Markdown**, géré dans le repo Git du projet (cf. [development-methodology](development-methodology.md#1-phase-de-développement)).
|
||||
|
||||
---
|
||||
|
||||
@@ -183,8 +183,8 @@ Vérifier que la description de la tâche est **présente dans le reten** avec *
|
||||
|
||||
## Related
|
||||
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) — workflow Git Flow où s'insèrent les revues (avant `Finish Feature`)
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) — la revue est faite avant l'intégration dans `develop` (phase 1)
|
||||
- [Custom Application Management](custom-application-management.md) — règles d'import/export pour éviter les modifs hors périmètre
|
||||
- [Development Methodology](development-methodology.md) — vue d'ensemble (reten, branches, custom apps)
|
||||
- [Kits](../concepts/kits.md) — utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage)
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) - workflow Git Flow où s'insèrent les revues (avant `Finish Feature`)
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) - la revue est faite avant l'intégration dans `develop` (phase 1)
|
||||
- [Custom Application Management](custom-application-management.md) - règles d'import/export pour éviter les modifs hors périmètre
|
||||
- [Development Methodology](development-methodology.md) - vue d'ensemble (reten, branches, custom apps)
|
||||
- [Kits](../concepts/kits.md) - utile pour comprendre les pièges sur `OutboundOrderOutboundOrderLineDetails` (kits sans assemblage)
|
||||
|
||||
@@ -43,7 +43,7 @@ Before configuring Easy WMS, verify the infrastructure:
|
||||
| Item | Requirement |
|
||||
|------|-------------|
|
||||
| **IIS version** | IIS 10+ on Windows Server 2019 or later |
|
||||
| **Application pools** | Main pool + Background Jobs pool + Integration pool — all configured as .NET CLR v4 |
|
||||
| **Application pools** | Main pool + Background Jobs pool + Integration pool - all configured as .NET CLR v4 |
|
||||
| **Database** | Oracle 19c+ or PostgreSQL 13+ |
|
||||
| **Environment variable** | `ASPNETCORE_ENVIRONMENT = Production` (not Development) |
|
||||
| **WIFI** | 802.11n/ac coverage in all RF terminal work areas; separate VLAN for WMS traffic |
|
||||
@@ -60,8 +60,8 @@ All physical warehouse configuration is done in **EasyS** (the visual layout con
|
||||
|
||||
1. Create the **warehouse** entity with type (manual / automatic / mixed).
|
||||
2. Define **sub-warehouses** if needed (physical separation or different logistics rules).
|
||||
3. Create **storage zones** — group aisles by temperature, hazard class, or ABC zone.
|
||||
4. Create **working zones** — assign equipment types with permission per process (reception, putaway, picking, replenishment, count).
|
||||
3. Create **storage zones** - group aisles by temperature, hazard class, or ABC zone.
|
||||
4. Create **working zones** - assign equipment types with permission per process (reception, putaway, picking, replenishment, count).
|
||||
|
||||
### 1.2 Location Types
|
||||
|
||||
@@ -91,11 +91,11 @@ For each process, at least one station of the appropriate type is required:
|
||||
|--------------|------|--------------|
|
||||
| Dock | 34 | Inbound/outbound vehicle docking |
|
||||
| Stage | 33 | Pre/post-dock staging |
|
||||
| PIE | — | Automatic inbound sorter |
|
||||
| PIE | - | Automatic inbound sorter |
|
||||
| PK conveyor | 2 | Picking/reception workstation |
|
||||
| ALM | — | Storage station |
|
||||
| ME/MU/MS | — | Multi-exit/multi-unit/multi-stock conveyors |
|
||||
| ET (Transit) | — | Intermediate replenishment station |
|
||||
| ALM | - | Storage station |
|
||||
| ME/MU/MS | - | Multi-exit/multi-unit/multi-stock conveyors |
|
||||
| ET (Transit) | - | Intermediate replenishment station |
|
||||
| Consolidation | 17 | Order consolidation |
|
||||
| Decision | 63 | Routing decision point |
|
||||
| Workzone | 64 | Manual picking zone |
|
||||
@@ -126,10 +126,10 @@ Defined in EasyS. Key attributes:
|
||||
|
||||
1. Create items in WMS UI or via **ITM ERP message**.
|
||||
2. Assign mandatory profiles:
|
||||
- **Reception profile** — required before any receipt can be created.
|
||||
- **Shipping profile** — required before any shipping order line can be assigned.
|
||||
- **Putaway profile** — optional; if absent, default warehouse strategy is used.
|
||||
- **Count profile** — required for ABC-driven cycle counts.
|
||||
- **Reception profile** - required before any receipt can be created.
|
||||
- **Shipping profile** - required before any shipping order line can be assigned.
|
||||
- **Putaway profile** - optional; if absent, default warehouse strategy is used.
|
||||
- **Count profile** - required for ABC-driven cycle counts.
|
||||
3. Configure logistic attributes (lot, expiry, serial number, quality, etc.) per item or item type.
|
||||
4. Set UoM and conversions; define base UoM clearly.
|
||||
5. For cutting stock items: assign cutting profile with min/max quantities, cutting tolerance, and label configuration.
|
||||
@@ -148,16 +148,16 @@ Defined in EasyS. Key attributes:
|
||||
|
||||
| Parameter | Default | Effect |
|
||||
|-----------|---------|--------|
|
||||
| `ALLOW_CREATE_RECEPTION` | — | Allow WMS to create a receipt without a pre-existing order |
|
||||
| `AutoCloseReception` | — | Auto-close receipt when all lines are fulfilled |
|
||||
| `USE_EXCLUSIVE_RESERVE_STRICT_MODE` | — | Block ASN reception if referenced receipt order is missing |
|
||||
| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | — | Minimum remaining shelf life required at reception |
|
||||
| `LPN_CHECK_CODE_GS1LABEL` | — | Validate LPN code against GS1 SSCC format |
|
||||
| `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS` | — | Prevent LPN code reuse (vs station codes, locations, aliases) |
|
||||
| `ALLOW_CREATE_RECEPTION` | - | Allow WMS to create a receipt without a pre-existing order |
|
||||
| `AutoCloseReception` | - | Auto-close receipt when all lines are fulfilled |
|
||||
| `USE_EXCLUSIVE_RESERVE_STRICT_MODE` | - | Block ASN reception if referenced receipt order is missing |
|
||||
| `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` | - | Minimum remaining shelf life required at reception |
|
||||
| `LPN_CHECK_CODE_GS1LABEL` | - | Validate LPN code against GS1 SSCC format |
|
||||
| `CONTAINER_CHECK_CODE_REPEATED_FOR_LABELS` | - | Prevent LPN code reuse (vs station codes, locations, aliases) |
|
||||
|
||||
### 3.2 PIE Station (Automatic Inbound)
|
||||
|
||||
Configure rejection handling — all PIE error types must have an explicit rejection route:
|
||||
Configure rejection handling - all PIE error types must have an explicit rejection route:
|
||||
|
||||
| Error Type | Destination |
|
||||
|------------|-------------|
|
||||
@@ -190,11 +190,11 @@ If receiving without RFT (containers enter PIE directly):
|
||||
|
||||
Putaway strategies execute in order. The recommended sequence for most deployments:
|
||||
|
||||
1. **Assigned location** (PDL / item-assigned location) — highest priority.
|
||||
2. **Channel filling** (compact, APS) — fill partially-occupied channels first.
|
||||
3. **Storage zone by ABC** — A-class items near pick face; C-class items at depth.
|
||||
4. **Crossdocking zone** (if applicable) — for items with `Enable crossdocking` active.
|
||||
5. **Default zone** — catch-all for any remaining containers.
|
||||
1. **Assigned location** (PDL / item-assigned location) - highest priority.
|
||||
2. **Channel filling** (compact, APS) - fill partially-occupied channels first.
|
||||
3. **Storage zone by ABC** - A-class items near pick face; C-class items at depth.
|
||||
4. **Crossdocking zone** (if applicable) - for items with `Enable crossdocking` active.
|
||||
5. **Default zone** - catch-all for any remaining containers.
|
||||
|
||||
Key strategy attributes:
|
||||
|
||||
@@ -208,19 +208,19 @@ Key strategy attributes:
|
||||
### 4.2 Restrictions
|
||||
|
||||
Configure restrictions to prevent mixing incompatible items in the same location/aisle/zone:
|
||||
- "Do not locate in same zone" — e.g., hazardous + non-hazardous.
|
||||
- "Do not locate in same aisle" — e.g., temperature classes.
|
||||
- "Do not fit on higher heights" — for fragile items.
|
||||
- "Do not putaway adjacent" — for certain chemical incompatibilities.
|
||||
- "Do not locate in same zone" - e.g., hazardous + non-hazardous.
|
||||
- "Do not locate in same aisle" - e.g., temperature classes.
|
||||
- "Do not fit on higher heights" - for fragile items.
|
||||
- "Do not putaway adjacent" - for certain chemical incompatibilities.
|
||||
|
||||
### 4.3 PDL Creation (Picking Dedicated Locations)
|
||||
|
||||
PDLs are configured per item per location. Required settings:
|
||||
- **Maximum stock level** — triggers top-off replenishment.
|
||||
- **Minimum stock level** — triggers stockout replenishment.
|
||||
- **Replenishment mode** — Container or Stock.
|
||||
- **Enable automatic replenishment** — must be explicitly checked.
|
||||
- **Delete when empty** — enable for seasonal items only.
|
||||
- **Maximum stock level** - triggers top-off replenishment.
|
||||
- **Minimum stock level** - triggers stockout replenishment.
|
||||
- **Replenishment mode** - Container or Stock.
|
||||
- **Enable automatic replenishment** - must be explicitly checked.
|
||||
- **Delete when empty** - enable for seasonal items only.
|
||||
|
||||
For locations with drawers/boxes (small parts): use partition labels with pre-generated coordinates. Enable `RF_PICKING_CONFIRM_LOCATION` to require location scan at picking.
|
||||
|
||||
@@ -241,11 +241,11 @@ When PDLs and stock source are in physically separate zones that cannot be direc
|
||||
|
||||
| Parameter | Default | Effect |
|
||||
|-----------|---------|--------|
|
||||
| `RF_PICKING_CONFIRM_LOCATION` | — | Require location scan before picking |
|
||||
| `MAX_CONTAINER_WEIGHT` | — | Client container weight limit |
|
||||
| `PICK_AND_PASS_ENABLED` | — | Enable Pick & Pass mode |
|
||||
| `VOICE_ENABLED` | — | Enable voice-guided picking |
|
||||
| `CUTTING_PRINTER` | — | Printer for cutting stock labels |
|
||||
| `RF_PICKING_CONFIRM_LOCATION` | - | Require location scan before picking |
|
||||
| `MAX_CONTAINER_WEIGHT` | - | Client container weight limit |
|
||||
| `PICK_AND_PASS_ENABLED` | - | Enable Pick & Pass mode |
|
||||
| `VOICE_ENABLED` | - | Enable voice-guided picking |
|
||||
| `CUTTING_PRINTER` | - | Printer for cutting stock labels |
|
||||
|
||||
### 5.2 PTL Configuration (Pick To Light / Put To Light)
|
||||
|
||||
@@ -286,7 +286,7 @@ When PDLs and stock source are in physically separate zones that cannot be direc
|
||||
|
||||
The `TryToReplenishProductLocations` background job runs automatically. Configure:
|
||||
- Job schedule (recommended: every 5–15 minutes).
|
||||
- `MAX_NUM_LOTS_REPLENISHMENT` — maximum lot lines per replenishment container (prevents mixing).
|
||||
- `MAX_NUM_LOTS_REPLENISHMENT` - maximum lot lines per replenishment container (prevents mixing).
|
||||
|
||||
### 6.3 Replenishment from Picking Locations
|
||||
|
||||
@@ -294,7 +294,7 @@ Used for locations with boxes/drawers (small parts):
|
||||
1. Assign minimum and maximum stock levels per PDL.
|
||||
2. Enable `Stockout` strategy.
|
||||
3. Place stock in a nearby storage location for FEFO/FIFO compliance.
|
||||
4. If FIFO/FEFO required: configure the PDL's source location to "take from height" — the system maintains the FEFO sequence during replenishment.
|
||||
4. If FIFO/FEFO required: configure the PDL's source location to "take from height" - the system maintains the FEFO sequence during replenishment.
|
||||
|
||||
---
|
||||
|
||||
@@ -321,7 +321,7 @@ Configure per lock type (in `Masters > Lock Types`):
|
||||
1. Create a **count schedule**: item ABC class, warehouse zones, and frequency (how many items per iteration).
|
||||
2. Create **count iterations** from the schedule: each iteration covers a subset of the total item population.
|
||||
3. Generate **count order** from iteration: produces location or item count tasks.
|
||||
4. Cycle count orders are **non-re-releasable** once canceled — create new orders if needed.
|
||||
4. Cycle count orders are **non-re-releasable** once canceled - create new orders if needed.
|
||||
|
||||
### 7.4 Double Validation
|
||||
|
||||
@@ -337,13 +337,13 @@ Enable per item (count profile) when count discrepancies require manager approva
|
||||
|
||||
Three mandatory configuration elements:
|
||||
|
||||
### Step 1 — Enable crossdocking on items
|
||||
### Step 1 - Enable crossdocking on items
|
||||
`Inventory > Items > item > "Enable crossdocking"` attribute = True.
|
||||
|
||||
### Step 2 — Configure crossdocking locations
|
||||
### Step 2 - Configure crossdocking locations
|
||||
In EasyS: activate **"Is crossdocking location"** on target locations.
|
||||
|
||||
### Step 3 — Create crossdocking putaway strategies
|
||||
### Step 3 - Create crossdocking putaway strategies
|
||||
- Create strategies with **"Crossdocking"** attribute enabled.
|
||||
- For placing loose stock (partial container): also enable **"Loose stock"** attribute.
|
||||
- For placing whole containers: use a strategy with "Crossdocking" only (no "Loose stock").
|
||||
@@ -400,7 +400,7 @@ Key message pairs to configure at go-live:
|
||||
### 10.2 Integration Application Pool
|
||||
|
||||
- Separate IIS pool from main application.
|
||||
- Monitor for stops — ERP messages queue if integration pool is down.
|
||||
- Monitor for stops - ERP messages queue if integration pool is down.
|
||||
- Log location: check both IIS logs and WMS application logs.
|
||||
|
||||
### 10.3 API Keys
|
||||
@@ -433,10 +433,10 @@ Key events to subscribe for go-live monitoring:
|
||||
|
||||
| Event | Severity | When to Subscribe |
|
||||
|-------|----------|--------------------|
|
||||
| `Notification_GNAImportError` | Error | Always — ERP message parsing failures |
|
||||
| `Notification_GNAImportError` | Error | Always - ERP message parsing failures |
|
||||
| AGV error codes (1001–2503) | Error | If AGV module active |
|
||||
| PS fault/tilt | Error | If Pallet Shuttle module active |
|
||||
| Stock failure on outbound order | Warning | Always — operational visibility |
|
||||
| Stock failure on outbound order | Warning | Always - operational visibility |
|
||||
|
||||
### 11.3 Yard Management
|
||||
|
||||
@@ -509,7 +509,7 @@ Create roles from most to least permissive; assign permissions explicitly per ro
|
||||
|
||||
Assign station roles to users/roles:
|
||||
- Role determines which station types the user can log into from the RFT.
|
||||
- Station role is checked at RFT login — rejected if not assigned.
|
||||
- Station role is checked at RFT login - rejected if not assigned.
|
||||
|
||||
### 12.3 Owner Isolation (3PL)
|
||||
|
||||
@@ -525,42 +525,42 @@ Assign station roles to users/roles:
|
||||
Key parameters to review at each deployment. Full documentation in [Parameters](../concepts/parameters.md).
|
||||
|
||||
### Reception
|
||||
- `ALLOW_CREATE_RECEPTION` — allow blind receipts
|
||||
- `AutoCloseReception` — auto-close on completion
|
||||
- `LPN_CHECK_CODE_GS1LABEL` — enforce GS1 SSCC format
|
||||
- `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` — shelf life check at receipt
|
||||
- `ALLOW_CREATE_RECEPTION` - allow blind receipts
|
||||
- `AutoCloseReception` - auto-close on completion
|
||||
- `LPN_CHECK_CODE_GS1LABEL` - enforce GS1 SSCC format
|
||||
- `RECEPTION_NUM_DAYS_PRODUCTION_DATE_MARGIN` - shelf life check at receipt
|
||||
|
||||
### Picking
|
||||
- `RF_PICKING_CONFIRM_LOCATION` — enforce location scan
|
||||
- `PICK_AND_PASS_ENABLED` — enable Pick & Pass mode
|
||||
- `VOICE_ENABLED` — enable voice picking
|
||||
- `RF_PICKING_CONFIRM_LOCATION` - enforce location scan
|
||||
- `PICK_AND_PASS_ENABLED` - enable Pick & Pass mode
|
||||
- `VOICE_ENABLED` - enable voice picking
|
||||
|
||||
### Replenishment
|
||||
- `MAX_NUM_LOTS_REPLENISHMENT` — lot mixing limit per container
|
||||
- `MAX_NUM_LOTS_REPLENISHMENT` - lot mixing limit per container
|
||||
- TryToReplenishProductLocations job schedule
|
||||
|
||||
### Defragmentation
|
||||
- `MAX_DEFRAG_TASKS` — max concurrent defragmentation tasks
|
||||
- `MAX_OPTIMIZATION_DEFRAG_CHANNEL` — max channels optimized per run
|
||||
- `MAX_DEFRAG_ATTEMPT` — retries before skipping a container
|
||||
- `MAX_DEFRAG_TASKS` - max concurrent defragmentation tasks
|
||||
- `MAX_OPTIMIZATION_DEFRAG_CHANNEL` - max channels optimized per run
|
||||
- `MAX_DEFRAG_ATTEMPT` - retries before skipping a container
|
||||
|
||||
### AGV / Pallet Shuttle
|
||||
- `PS_MAX_MINUTES_BATTERY_FULL_LOAD` = 300 (max battery life under load)
|
||||
- `PS_MIN_MINUTES_BATTERY_LOAD` = 90 (minimum before return to charge)
|
||||
|
||||
### Multi-Carrier
|
||||
- `MC_TRACKING_ARCHIVES_PATH` — carrier tracking files directory
|
||||
- `MC_DEFAULT_CARRIER` — fallback carrier if auto-selection fails
|
||||
- `MC_TRACKING_ARCHIVES_PATH` - carrier tracking files directory
|
||||
- `MC_DEFAULT_CARRIER` - fallback carrier if auto-selection fails
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Parameters](../concepts/parameters.md) — Complete parameter reference with all values
|
||||
- [Troubleshooting](troubleshooting.md) — Error resolution guide
|
||||
- [Stations & Routes](../concepts/stations.md) — Full station type reference
|
||||
- [Warehouse Designer](../concepts/warehouse-designer.md) — EasyS-based layout configuration
|
||||
- [Putaway](../concepts/putaway.md) — Strategy pipeline and configuration details
|
||||
- [Replenishment](../concepts/replenishment.md) — PDL and strategy configuration details
|
||||
- [System Architecture](../architecture/overview.md) — IIS, pools, and background jobs
|
||||
- [Security](../architecture/security.md) — Roles, authentication, and permissions
|
||||
- [Parameters](../concepts/parameters.md) - Complete parameter reference with all values
|
||||
- [Troubleshooting](troubleshooting.md) - Error resolution guide
|
||||
- [Stations & Routes](../concepts/stations.md) - Full station type reference
|
||||
- [Warehouse Designer](../concepts/warehouse-designer.md) - EasyS-based layout configuration
|
||||
- [Putaway](../concepts/putaway.md) - Strategy pipeline and configuration details
|
||||
- [Replenishment](../concepts/replenishment.md) - PDL and strategy configuration details
|
||||
- [System Architecture](../architecture/overview.md) - IIS, pools, and background jobs
|
||||
- [Security](../architecture/security.md) - Roles, authentication, and permissions
|
||||
|
||||
@@ -29,13 +29,13 @@ Règles de base :
|
||||
|
||||
> ⛔ Une mauvaise manipulation ici peut entraîner la **perte de vos développements**. Procéder avec soin.
|
||||
|
||||
Source : Confluence EasyWMS France — *Gestion de la custom application* (v12, 20/12/2022).
|
||||
Source : Confluence EasyWMS France - *Gestion de la custom application* (v12, 20/12/2022).
|
||||
|
||||
## <a id="creation"></a>1. Création de l'application custom
|
||||
|
||||
À n'exécuter qu'**une seule fois par projet** (le premier développeur). Les autres devs font un **Import** (cf. section 2).
|
||||
|
||||
### Option A — Partir d'une app existante du Toolkit
|
||||
### Option A - Partir d'une app existante du Toolkit
|
||||
|
||||
Si le projet réutilise des modifications déjà packagées dans le dépôt [**FRANCE_OPERATIONS_TOOLS**](https://msscode.mecalux.com/Proyectos_SW/FRANCE_OPERATIONS_TOOLS.git) (ex. modifications habituelles du module transporteur) :
|
||||
|
||||
@@ -46,7 +46,7 @@ Si le projet réutilise des modifications déjà packagées dans le dépôt [**F
|
||||
```
|
||||
Exemple : `..\FRANCE_OPERATIONS_TOOLS\Module transporteur`
|
||||
|
||||
### Option B — Créer une application vierge
|
||||
### Option B - Créer une application vierge
|
||||
|
||||
Dans **EasyBuilder** :
|
||||
|
||||
@@ -78,7 +78,7 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt
|
||||
| Vous rejoignez un projet en cours | **Oui** (première action) |
|
||||
| Vous venez de merger votre branche dans `develop` | **Oui** (réimporter le `develop` à jour) |
|
||||
| Un collègue a poussé une modif majeure sur `develop` | **Oui** après `git pull` |
|
||||
| Vous démarrez la journée sur votre branche perso | **Non** — travailler sur votre export local |
|
||||
| Vous démarrez la journée sur votre branche perso | **Non** - travailler sur votre export local |
|
||||
|
||||
## <a id="export"></a>3. Export de l'application custom
|
||||
|
||||
@@ -104,7 +104,7 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt
|
||||
|
||||
### Suites logiques
|
||||
|
||||
- **Commit + push** sur la branche de votre tâche — cf. [git-workflow](git-workflow.md#3--commit-de-vos-modifications)
|
||||
- **Commit + push** sur la branche de votre tâche - cf. [git-workflow](git-workflow.md#3-commit-de-vos-modifications)
|
||||
- Les fichiers exportés peuvent être **séparés en plusieurs** pour un même élément AD (workflow, source C#, DESIGN…). Bien prendre **tous** les fichiers portant le nom de l'élément modifié.
|
||||
|
||||
## Règles de coexistence multi-développeurs
|
||||
@@ -113,7 +113,7 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt
|
||||
|-----------|--------|
|
||||
| Plusieurs devs sur le projet | Chacun sur sa **branche GIT personnelle** (cf. [development-methodology](development-methodology.md)) |
|
||||
| Éviter les écrasements | **Export systématique** en fin de tâche + **import** après merge dans `develop` |
|
||||
| Éléments en Check-out | À **Check-in avant export** — sinon perte silencieuse |
|
||||
| Éléments en Check-out | À **Check-in avant export** - sinon perte silencieuse |
|
||||
| Structure commune (toolkit) | Utiliser **FRANCE_OPERATIONS_TOOLS** en option A de création |
|
||||
|
||||
## Common errors
|
||||
@@ -127,8 +127,8 @@ Après création, faire un **1ᵉʳ export sur la branche `develop`** du dépôt
|
||||
|
||||
## Related
|
||||
|
||||
- [Application Dictionary](../architecture/application-dictionary.md) — contenu packagé dans la custom app (Commands, Queries, Entities, Views, Dialogs, Events, Workflows)
|
||||
- [Development Methodology](development-methodology.md) — stratégie de branches et cadre dans lequel s'inscrit la gestion de la custom app
|
||||
- [First Deployment](first-deployment.md) — création initiale de la custom app (étape 9) et référencement dans `DeployConfig.yaml` (étape 10)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — import custom app lors d'un redéploiement (étape 6 si anciens scripts)
|
||||
- [Git Workflow](git-workflow.md) — rythme commit/push et gestion des branches
|
||||
- [Application Dictionary](../architecture/application-dictionary.md) - contenu packagé dans la custom app (Commands, Queries, Entities, Views, Dialogs, Events, Workflows)
|
||||
- [Development Methodology](development-methodology.md) - stratégie de branches et cadre dans lequel s'inscrit la gestion de la custom app
|
||||
- [First Deployment](first-deployment.md) - création initiale de la custom app (étape 9) et référencement dans `DeployConfig.yaml` (étape 10)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - import custom app lors d'un redéploiement (étape 6 si anciens scripts)
|
||||
- [Git Workflow](git-workflow.md) - rythme commit/push et gestion des branches
|
||||
|
||||
@@ -27,7 +27,7 @@ Procédure interne Mecalux EasyWMS France pour **livrer un lot de développement
|
||||
|
||||
Le pivot de la procédure est la **création d'un tag Git** sur le commit `develop` choisi : cela garantit que la version déployée et testée par le CdP est **figée**, indépendamment de tout commit ultérieur sur `develop` (potentiellement en cours de dev / non testé).
|
||||
|
||||
Source : Confluence EasyWMS France — *Déployer l'application en test* (v1, 20/12/2022).
|
||||
Source : Confluence EasyWMS France - *Déployer l'application en test* (v1, 20/12/2022).
|
||||
|
||||
## Convention de nommage des tags
|
||||
|
||||
@@ -64,7 +64,7 @@ git checkout <Tag Name>
|
||||
|
||||
Appliquer le point de contrôle Hyper-V **"Deploy 0"** sur la VM de test **avant** le déploiement.
|
||||
|
||||
> Le checkpoint "Deploy 0" est créé à la fin de la procédure d'installation initiale de la VM (cf. [vm-installation](vm-installation.md)) — c'est l'état "VM prête à recevoir un déploiement, vide de tout projet".
|
||||
> Le checkpoint "Deploy 0" est créé à la fin de la procédure d'installation initiale de la VM (cf. [vm-installation](vm-installation.md)) - c'est l'état "VM prête à recevoir un déploiement, vide de tout projet".
|
||||
|
||||
### 3. Déploiement de l'application existante
|
||||
|
||||
@@ -74,7 +74,7 @@ Suivre la procédure complète : [deployment-existing-app](deployment-existing-a
|
||||
|
||||
### 4. Réinstallation du GNA (si besoin)
|
||||
|
||||
Si la livraison contient des modifications BOO du GNA → réinstaller le GNA : [gna-services-license — Réinstallation](gna-services-license.md#réinstallation-du-gna).
|
||||
Si la livraison contient des modifications BOO du GNA → réinstaller le GNA : [gna-services-license - Réinstallation](gna-services-license.md#réinstallation-dun-gna).
|
||||
|
||||
### 5. Installer le **printer service** et la **licence**
|
||||
|
||||
@@ -82,9 +82,9 @@ Suivre la procédure : [gna-services-license](gna-services-license.md) (sections
|
||||
|
||||
### 6. Valider la VM
|
||||
|
||||
Procédure de validation post-déploiement : [vm-installation — Validation](vm-installation.md#validation-de-la-vm).
|
||||
Procédure de validation post-déploiement : [vm-installation - Validation](vm-installation.md#validation-de-la-vm).
|
||||
|
||||
> En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP — utiliser les ports NAT ([vm-network-routing](vm-network-routing.md)) si la VM de test est sur un autre poste.
|
||||
> En particulier vérifier l'accès SmartUI / consoleRF / EasySTS depuis le PC du CdP - utiliser les ports NAT ([vm-network-routing](vm-network-routing.md)) si la VM de test est sur un autre poste.
|
||||
|
||||
### 7. Mise à jour des tâches Jira
|
||||
|
||||
@@ -117,10 +117,10 @@ Le tag fige le commit → la livraison est **reproductible** et **garantie sans
|
||||
|
||||
## Related
|
||||
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) — phase "développement initial", quand cette procédure s'applique
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git détaillées (CLI / SourceTree)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — procédure de redéploiement réutilisée à l'étape 3
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) — procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici)
|
||||
- [GNA, Services & License](gna-services-license.md) — étapes 4 (réinstallation GNA) et 5 (printer + licence)
|
||||
- [VM Installation & Validation](vm-installation.md) — checkpoint "Deploy 0" et validation post-déploiement
|
||||
- [VM Network Routing](vm-network-routing.md) — accès distant à la VM de test depuis le PC du CdP
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) - phase "développement initial", quand cette procédure s'applique
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) - opérations Git détaillées (CLI / SourceTree)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - procédure de redéploiement réutilisée à l'étape 3
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) - procédure jumelle pour figer un commit sur sa propre VM de dev (vs VM de test partagée ici)
|
||||
- [GNA, Services & License](gna-services-license.md) - étapes 4 (réinstallation GNA) et 5 (printer + licence)
|
||||
- [VM Installation & Validation](vm-installation.md) - checkpoint "Deploy 0" et validation post-déploiement
|
||||
- [VM Network Routing](vm-network-routing.md) - accès distant à la VM de test depuis le PC du CdP
|
||||
|
||||
@@ -26,9 +26,9 @@ Procédure de **redéploiement** d'un projet EasyWMS déjà initialisé sur une
|
||||
|
||||
Elle **ne couvre pas le premier déploiement** d'un projet neuf (cf. [first-deployment](first-deployment.md)), ni le déploiement d'un commit figé (cf. [deployment-specific-commit](deployment-specific-commit.md)).
|
||||
|
||||
Source : Confluence EasyWMS France — *Déploiement d'une application existante* (v20, 04/07/2024).
|
||||
Source : Confluence EasyWMS France - *Déploiement d'une application existante* (v20, 04/07/2024).
|
||||
|
||||
## Étape 1 — Vérifier `env.secrets.yaml`
|
||||
## Étape 1 - Vérifier `env.secrets.yaml`
|
||||
|
||||
Dans **`C:\deploy\env.secrets.yaml`** sur la VM, vérifier les paramètres BDD :
|
||||
|
||||
@@ -46,7 +46,7 @@ Dans **`C:\deploy\env.secrets.yaml`** sur la VM, vérifier les paramètres BDD :
|
||||
| `Server` | `localhost` |
|
||||
| `Password` (toutes BDD) | `robmec` |
|
||||
|
||||
## Étape 2 — Déploiement complet
|
||||
## Étape 2 - Déploiement complet
|
||||
|
||||
Ouvrir **PowerShell en administrateur** dans **`C:\deploy`** de la VM (`cd C:\deploy`).
|
||||
|
||||
@@ -76,13 +76,13 @@ Exemple :
|
||||
|
||||
À exécuter uniquement si le projet repose encore sur les anciens scripts (pas `deploy_repository.ps1`).
|
||||
|
||||
### 3 — Deploy 1 (Complete)
|
||||
### 3 - Deploy 1 (Complete)
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1 # choisir "1. Complete"
|
||||
```
|
||||
|
||||
### 4 — Intégrer la config entrepôt (Load)
|
||||
### 4 - Intégrer la config entrepôt (Load)
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1 # choisir "2. Load"
|
||||
@@ -94,7 +94,7 @@ Charge :
|
||||
|
||||
> Alternative : **EasyS → Transfert Data** vers la VM.
|
||||
|
||||
### 5 — Assignation utilisateur
|
||||
### 5 - Assignation utilisateur
|
||||
|
||||
```powershell
|
||||
.\Commands\commands.ps1
|
||||
@@ -102,13 +102,13 @@ Charge :
|
||||
|
||||
Ou via **SmartUI → Organisation → Utilisateurs** → éditer `mecalux` → ajouter les sites autorisés.
|
||||
|
||||
### 6 — Import de l'application custom
|
||||
### 6 - Import de l'application custom
|
||||
|
||||
Voir [custom-application-management — Import](custom-application-management.md#import).
|
||||
Voir [custom-application-management - Import](custom-application-management.md#import).
|
||||
|
||||
## Étape 7 — Désactiver les instances en BDD (OBLIGATOIRE)
|
||||
## Étape 7 - Désactiver les instances en BDD (OBLIGATOIRE)
|
||||
|
||||
> ⚠️ Sans cette étape, **les instances ne fonctionneront pas** — cette modification est requise à **chaque redéploiement** (le fichier `Tenants.xml` est régénéré).
|
||||
> ⚠️ Sans cette étape, **les instances ne fonctionneront pas** - cette modification est requise à **chaque redéploiement** (le fichier `Tenants.xml` est régénéré).
|
||||
|
||||
Dans **`C:\inetpub\wwwroot\ApplicationService\Tenants.xml`**, remplacer :
|
||||
|
||||
@@ -148,9 +148,9 @@ Puis : `iisreset` ou recyclage du pool **ApplicationService**.
|
||||
|
||||
## Related
|
||||
|
||||
- [VM Installation](vm-installation.md) — pré-requis VM + validation
|
||||
- [First Deployment](first-deployment.md) — à lire d'abord si le projet n'a jamais été déployé
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) — variante pour cibler un commit figé plutôt qu'un HEAD de branche
|
||||
- [Custom Application Management](custom-application-management.md) — import/export de la custom app
|
||||
- [Git Workflow](git-workflow.md) — sélection de la branche cible
|
||||
- [GNA, Services & License](gna-services-license.md) — réinstaller GNA après redéploiement si scripts BOO modifiés
|
||||
- [VM Installation](vm-installation.md) - pré-requis VM + validation
|
||||
- [First Deployment](first-deployment.md) - à lire d'abord si le projet n'a jamais été déployé
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) - variante pour cibler un commit figé plutôt qu'un HEAD de branche
|
||||
- [Custom Application Management](custom-application-management.md) - import/export de la custom app
|
||||
- [Git Workflow](git-workflow.md) - sélection de la branche cible
|
||||
- [GNA, Services & License](gna-services-license.md) - réinstaller GNA après redéploiement si scripts BOO modifiés
|
||||
|
||||
@@ -23,7 +23,7 @@ Procédure pour déployer une VM de développement sur un **commit figé** plut
|
||||
|
||||
Le principe : créer un tag GIT sur le commit cible, créer une branche à partir de ce tag, puis utiliser le mécanisme standard de déploiement par branche (`deploy_repository.ps1 <Projet> <Branche>`).
|
||||
|
||||
Source : Confluence EasyWMS France — *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023).
|
||||
Source : Confluence EasyWMS France - *Déploiement d'une VM sur un commit spécifique* (v3, 09/06/2023).
|
||||
|
||||
## Prérequis
|
||||
|
||||
@@ -78,14 +78,14 @@ Côté VM, utiliser le script de déploiement standard en référençant la nouv
|
||||
.\deploy_repository.ps1 NomDuProjetGit NomDeLaNouvelleBranche
|
||||
```
|
||||
|
||||
La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7--désactiver-les-instances-en-bdd-obligatoire).
|
||||
La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard de redéploiement : cf. [deployment-existing-app](deployment-existing-app.md#étape-7---désactiver-les-instances-en-bdd-obligatoire).
|
||||
|
||||
## Règles pratiques
|
||||
|
||||
- **Un tag + une branche par version à déployer** — ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche).
|
||||
- **Nommage `<PREFIXE>-V<N>` incrémental** — facilite la lecture de l'historique et le support côté client.
|
||||
- **Fetch all tags avant toute opération** — sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible.
|
||||
- **Pousser tags et branches** — si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable.
|
||||
- **Un tag + une branche par version à déployer** - ne jamais forcer le déploiement directement sur un commit détaché, qui échapperait au script de déploiement (basé sur branche).
|
||||
- **Nommage `<PREFIXE>-V<N>` incrémental** - facilite la lecture de l'historique et le support côté client.
|
||||
- **Fetch all tags avant toute opération** - sinon risque de recréer un tag qui existe déjà, ou de manquer la version cible.
|
||||
- **Pousser tags et branches** - si l'autre dev / l'environnement de test doit pouvoir y accéder, le push est indispensable.
|
||||
|
||||
## Common errors
|
||||
|
||||
@@ -96,6 +96,6 @@ La suite (Tenants.xml → `InMemory`, `iisreset`…) suit la procédure standard
|
||||
|
||||
## Related
|
||||
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — procédure de déploiement standard (référencée en étape 4)
|
||||
- [First Deployment](first-deployment.md) — première initialisation d'un projet
|
||||
- [Git Workflow](git-workflow.md) — stratégie de branches générale
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - procédure de déploiement standard (référencée en étape 4)
|
||||
- [First Deployment](first-deployment.md) - première initialisation d'un projet
|
||||
- [Git Workflow](git-workflow.md) - stratégie de branches générale
|
||||
|
||||
@@ -22,10 +22,10 @@ Méthode de développement interne Mecalux EasyWMS France pour les **custom appl
|
||||
|
||||
Objectifs :
|
||||
|
||||
1. **Réduire les temps de compilation** — chaque développeur compile uniquement sa propre branche
|
||||
1. **Réduire les temps de compilation** - chaque développeur compile uniquement sa propre branche
|
||||
2. **Distinguer clairement** trois états : ce qui est **en production**, ce qui est **à livrer** (validé, prêt pour release) et ce qui est **en cours de développement** (non validé)
|
||||
|
||||
Référence source : Confluence EasyWMS France — *Présentation méthode de développement* (v8, 29/12/2023).
|
||||
Référence source : Confluence EasyWMS France - *Présentation méthode de développement* (v8, 29/12/2023).
|
||||
|
||||
## Stratégie de branches GIT
|
||||
|
||||
@@ -49,7 +49,7 @@ Référence source : Confluence EasyWMS France — *Présentation méthode de d
|
||||
|
||||
1. Lorsqu'une partie ou la totalité des développements est terminée, la custom application est déployée sur une **machine dédiée hébergée sur le serveur de test**.
|
||||
2. Les **testeurs** testent depuis ce serveur sans avoir à monter une machine sur leur propre PC.
|
||||
3. Correction des bugs — **deux options** (point à valider selon le chantier) :
|
||||
3. Correction des bugs - **deux options** (point à valider selon le chantier) :
|
||||
- **Option A** : le développeur corrige **directement sur le serveur de test**.
|
||||
- **Option B** : le développeur corrige sur sa **machine de développement locale** puis **redéploie sur le serveur de test**.
|
||||
|
||||
@@ -75,10 +75,10 @@ post-production ───────────────● ─── (cré
|
||||
|
||||
## Règles pratiques
|
||||
|
||||
- **Ne jamais committer directement sur `master`** — toute modification passe par `développement` puis release.
|
||||
- **Ne jamais merger `post-production` prématurément** — cela écraserait des correctifs présents sur `master`.
|
||||
- **Ne jamais committer directement sur `master`** - toute modification passe par `développement` puis release.
|
||||
- **Ne jamais merger `post-production` prématurément** - cela écraserait des correctifs présents sur `master`.
|
||||
- **Redéploiement de la custom app après chaque merge/rebase** pour vérifier que la compilation passe et que l'app démarre.
|
||||
- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement — la conversion vers DOC n'intervient qu'en fin de chantier.
|
||||
- **Fichier Markdown obligatoire pour le manuel de reten** durant tout le développement - la conversion vers DOC n'intervient qu'en fin de chantier.
|
||||
|
||||
## Common errors
|
||||
|
||||
@@ -89,6 +89,6 @@ post-production ───────────────● ─── (cré
|
||||
|
||||
## Related
|
||||
|
||||
- [System Architecture Overview](../architecture/overview.md) — contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
|
||||
- [Application Dictionary](../architecture/application-dictionary.md) — éléments AD packagés dans la custom app
|
||||
- [Configuration Guide](configuration-guide.md) — configuration post-déploiement
|
||||
- [System Architecture Overview](../architecture/overview.md) - contexte de déploiement custom apps (IIS, compilation, SaaS vs on-premise)
|
||||
- [Application Dictionary](../architecture/application-dictionary.md) - éléments AD packagés dans la custom app
|
||||
- [Configuration Guide](configuration-guide.md) - configuration post-déploiement
|
||||
|
||||
@@ -26,9 +26,9 @@ Procédure de **premier déploiement** d'un projet EasyWMS sur une VM de dévelo
|
||||
|
||||
Cette procédure n'est exécutée qu'**une seule fois par projet**. Pour tous les déploiements ultérieurs (autre dev rejoignant le projet, redéploiement après modif), voir [deployment-existing-app](deployment-existing-app.md).
|
||||
|
||||
Source : Confluence EasyWMS France — *Premier déploiement* (v39, 07/08/2025).
|
||||
Source : Confluence EasyWMS France - *Premier déploiement* (v39, 07/08/2025).
|
||||
|
||||
## Étape 1 — `DeployConfig.yaml`
|
||||
## Étape 1 - `DeployConfig.yaml`
|
||||
|
||||
Le fichier **`build/DeployConfig.yaml`** du dépôt GIT du projet pilote le déploiement. S'il est absent, le télécharger et l'y placer. Champs critiques à vérifier :
|
||||
|
||||
@@ -79,7 +79,7 @@ Data: test
|
||||
|
||||
### StandardApplications
|
||||
|
||||
Les applications à installer — reprendre la liste `<ExtraApps>` du `responses.xml` du projet, en ne gardant que celles avec `Use="Yes"` :
|
||||
Les applications à installer - reprendre la liste `<ExtraApps>` du `responses.xml` du projet, en ne gardant que celles avec `Use="Yes"` :
|
||||
|
||||
```yaml
|
||||
StandardApplications:
|
||||
@@ -88,7 +88,7 @@ StandardApplications:
|
||||
|
||||
### EnabledModules
|
||||
|
||||
Liste complète des modules à activer — reprendre la balise `<Modules>` du `responses.xml`, **sauf `EasyWMS`** (inclus par défaut).
|
||||
Liste complète des modules à activer - reprendre la balise `<Modules>` du `responses.xml`, **sauf `EasyWMS`** (inclus par défaut).
|
||||
|
||||
> ⚠️ **Problème connu versions 24.xx.xx.xx** : l'étape *"Importing apps with AD..."* peut durer très longtemps et échouer avec une erreur `System.Management.Automation.RuntimeException`. Dans ce cas, ajouter **`ToggleService`** à la liste.
|
||||
|
||||
@@ -127,7 +127,7 @@ EnabledModules:
|
||||
|
||||
### Customs (application custom)
|
||||
|
||||
Laisser **vide pour ce premier déploiement** — renseigné à l'étape 10.
|
||||
Laisser **vide pour ce premier déploiement** - renseigné à l'étape 10.
|
||||
|
||||
### Users
|
||||
|
||||
@@ -140,13 +140,13 @@ Users:
|
||||
Groups: SuperAdmin,Administrators,Managers,Operators
|
||||
```
|
||||
|
||||
## Étape 2 — Déposer le fichier de layout EasyS
|
||||
## Étape 2 - Déposer le fichier de layout EasyS
|
||||
|
||||
Placer le fichier de configuration entrepôt EasyS (ex : `MAPAB_layout.cfg2014`) dans le dossier **`layout_config/`** du dépôt GIT.
|
||||
|
||||
> ⚠️ Bien **commit et push** après dépôt — le script de déploiement clone le GIT.
|
||||
> ⚠️ Bien **commit et push** après dépôt - le script de déploiement clone le GIT.
|
||||
|
||||
## Étape 3 — Vérifier `env.secrets.yaml` sur la VM
|
||||
## Étape 3 - Vérifier `env.secrets.yaml` sur la VM
|
||||
|
||||
Dans **`C:\deploy\env.secrets.yaml`** de la VM, vérifier que les paramètres BDD correspondent à la BDD de la VM :
|
||||
|
||||
@@ -156,7 +156,7 @@ Dans **`C:\deploy\env.secrets.yaml`** de la VM, vérifier que les paramètres BD
|
||||
| `Server` | `localhost/orcl` (Oracle) / `localhost` (PostgreSQL) |
|
||||
| `Password` (toutes BDD) | `robmec` |
|
||||
|
||||
## Étape 4 — Déploiement complet (script unifié)
|
||||
## Étape 4 - Déploiement complet (script unifié)
|
||||
|
||||
Ouvrir **PowerShell en administrateur** dans **`C:\deploy`** de la VM :
|
||||
|
||||
@@ -188,13 +188,13 @@ Exemple :
|
||||
|
||||
À n'exécuter que si le projet utilise les **anciens scripts** `deploy.ps1` + `commands.ps1` (pas `deploy_repository.ps1`).
|
||||
|
||||
### 5 — Deploy 1 (Complete)
|
||||
### 5 - Deploy 1 (Complete)
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1 # choisir "1. Complete"
|
||||
```
|
||||
|
||||
### 6 — Load (config entrepôt + paramètres uGNA)
|
||||
### 6 - Load (config entrepôt + paramètres uGNA)
|
||||
|
||||
```powershell
|
||||
.\deploy.ps1 # choisir "2. Load"
|
||||
@@ -206,7 +206,7 @@ Ce qui est chargé :
|
||||
|
||||
> Alternative : charger le layout via **EasyS → Transfert Data** vers la VM.
|
||||
|
||||
### 7 — Assignation utilisateur
|
||||
### 7 - Assignation utilisateur
|
||||
|
||||
```powershell
|
||||
.\Commands\commands.ps1
|
||||
@@ -214,7 +214,7 @@ Ce qui est chargé :
|
||||
|
||||
Alternative SmartUI : **Organisation → Utilisateurs** → sélectionner `mecalux` → ajouter les sites autorisés.
|
||||
|
||||
## Étape 8 — Désactiver les instances en BDD (OBLIGATOIRE)
|
||||
## Étape 8 - Désactiver les instances en BDD (OBLIGATOIRE)
|
||||
|
||||
> ⚠️ **Sans cette modification, les instances ne fonctionnent pas.**
|
||||
|
||||
@@ -241,13 +241,13 @@ Activer le mode **Regular expression** dans `Replace` (`Ctrl+H`) :
|
||||
|
||||
Chaque occurrence est remplacée en conservant le nom de Tenant.
|
||||
|
||||
## Étape 9 — Créer l'application custom
|
||||
## Étape 9 - Créer l'application custom
|
||||
|
||||
Procéder à la création initiale de la custom app et son premier export sur GIT.
|
||||
|
||||
Voir [custom-application-management — Création](custom-application-management.md#creation).
|
||||
Voir [custom-application-management - Création](custom-application-management.md#creation).
|
||||
|
||||
## Étape 10 — Compléter `DeployConfig.yaml` avec le Custom
|
||||
## Étape 10 - Compléter `DeployConfig.yaml` avec le Custom
|
||||
|
||||
Une fois la custom app créée et exportée, renseigner la section `Customs` :
|
||||
|
||||
@@ -270,7 +270,7 @@ Désormais, chaque déploiement ultérieur (`deploy_repository.ps1`) reprendra a
|
||||
| Clé | Type | Rôle |
|
||||
|-----|------|------|
|
||||
| `TenantName` / `TenantCode` | string | Identifiant du tenant EasyWMS |
|
||||
| `DBEngine` | enum | `Oracle` / `PostgreSQL` / `SQLServer` / `MySQL` — doit matcher `env.secrets.yaml` |
|
||||
| `DBEngine` | enum | `Oracle` / `PostgreSQL` / `SQLServer` / `MySQL` - doit matcher `env.secrets.yaml` |
|
||||
| `MAPSeed` | string (version) | Version WMS à déployer depuis mapdeploy |
|
||||
| `License` | enum | `PRO` / `ADVANCE` / `ENTERPRISE` |
|
||||
| `Warehouse` | path | Chemin relatif layout EasyS (`.cfg2014`) |
|
||||
@@ -291,11 +291,11 @@ Désormais, chaque déploiement ultérieur (`deploy_repository.ps1`) reprendra a
|
||||
|
||||
## Related
|
||||
|
||||
- [VM Installation](vm-installation.md) — pré-requis : VM Hyper-V créée et validée
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — déploiements ultérieurs (autres devs, redéploiement, changement de branche)
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) — déployer un commit figé plutôt que le HEAD d'une branche
|
||||
- [Custom Application Management](custom-application-management.md) — étape 9 (création initiale de la custom app)
|
||||
- [Git Workflow](git-workflow.md) — stratégie de branches pour le projet
|
||||
- [GNA, Services & License](gna-services-license.md) — installation des services GNA, Printer, License WMS après déploiement
|
||||
- [System Architecture Overview](../architecture/overview.md) — stack cible (IIS, BDD, services)
|
||||
- [Parameters](../concepts/parameters.md) — paramètres WMS chargés via uGNA (étape 6)
|
||||
- [VM Installation](vm-installation.md) - pré-requis : VM Hyper-V créée et validée
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - déploiements ultérieurs (autres devs, redéploiement, changement de branche)
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) - déployer un commit figé plutôt que le HEAD d'une branche
|
||||
- [Custom Application Management](custom-application-management.md) - étape 9 (création initiale de la custom app)
|
||||
- [Git Workflow](git-workflow.md) - stratégie de branches pour le projet
|
||||
- [GNA, Services & License](gna-services-license.md) - installation des services GNA, Printer, License WMS après déploiement
|
||||
- [System Architecture Overview](../architecture/overview.md) - stack cible (IIS, BDD, services)
|
||||
- [Parameters](../concepts/parameters.md) - paramètres WMS chargés via uGNA (étape 6)
|
||||
|
||||
@@ -25,7 +25,7 @@ last_compiled: "2026-04-17"
|
||||
EasyS is the 3D simulation front-end that speaks the same protocol as GALILEO. Running EasyS + EasyWMS Gateway on a dev VM lets you reproduce the full robotic flow (PIE → Miniload → PK → PS) without physical hardware. This page covers Gateway install, EasyS simulation configuration, PIE event injection, pick/shipping test flows, and station/route synchronisation procedures.
|
||||
|
||||
Shared demo environment (Mecalux France):
|
||||
- VM **ALL** on server **LYOITSW02** — IP `10.58.10.75`
|
||||
- VM **ALL** on server **LYOITSW02** - IP `10.58.10.75`
|
||||
- Credentials: `mecalux / mecalux`
|
||||
- Warehouse: `WRH_MIXTE` (miniload + conveyor path)
|
||||
|
||||
@@ -45,10 +45,10 @@ File: `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Config\MainObject.config`
|
||||
|
||||
1. Set **tenantCode** = the WMS tenant you want to target
|
||||
2. Fill the **TokenUser** connection section (not `ClientUser`)
|
||||
3. Passwords must be encrypted — run `PasswordEncrypt.exe` from `C:\Program Files\Mecalux\EasyWMS Gateway 2015`
|
||||
3. Passwords must be encrypted - run `PasswordEncrypt.exe` from `C:\Program Files\Mecalux\EasyWMS Gateway 2015`
|
||||
4. Start the Windows service **EasyWMSGateway2015**
|
||||
|
||||
Logs go to `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log` — see [Galileo Troubleshooting](galileo-troubleshooting.md).
|
||||
Logs go to `C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log` - see [Galileo Troubleshooting](galileo-troubleshooting.md).
|
||||
|
||||
## 2. Open port 3000 on the VM
|
||||
|
||||
@@ -82,8 +82,8 @@ Every miniload location must be bound to a **rack type** with the exact dimensio
|
||||
|
||||
At each PIE pass, GALILEO returns:
|
||||
|
||||
- **PLC Container Type** — derived from width
|
||||
- **PLC Height Type** — derived from height
|
||||
- **PLC Container Type** - derived from width
|
||||
- **PLC Height Type** - derived from height
|
||||
|
||||
Procedure:
|
||||
|
||||
@@ -108,10 +108,10 @@ To simulate a TK, add an **Automatic Aisle**. The aisle ↔ rack link works like
|
||||
| Automatic Aisle | Stacker crane / Miniload |
|
||||
| PIE | Entry identification (label + weigh) |
|
||||
| Picking (PK) | Picking conveyor |
|
||||
| PKE | PK entry control — if full, recirculate |
|
||||
| PKE | PK entry control - if full, recirculate |
|
||||
| Inbound Table (ME) | Conveyor into the TK/Miniload |
|
||||
| Outbound Table (MS) | Conveyor out of the TK/Miniload |
|
||||
| CME | TK/Miniload entry control — if full, recirculate |
|
||||
| CME | TK/Miniload entry control - if full, recirculate |
|
||||
| Outbound Post | Exit conveyor (operator can pick the container up) |
|
||||
| MP | Preparation table (stock drop after pick) |
|
||||
| Transporter | Plain conveyor with no special function |
|
||||
@@ -122,12 +122,12 @@ Full catalogue: [Stations & Routes](../concepts/stations.md); translation matrix
|
||||
|
||||
Two layout patterns for double-depth racks:
|
||||
|
||||
- **Case #1** (most common at Mecalux France) — best for **mono-product** supports (several supports share the same item inside the TK). Rotation zones split by front face / rear face.
|
||||
- **Case #2** — best for **multi-product** supports (a given item never lives in two supports simultaneously). Reduces relocations during picking without pre-emptive defragmentation.
|
||||
- **Case #1** (most common at Mecalux France) - best for **mono-product** supports (several supports share the same item inside the TK). Rotation zones split by front face / rear face.
|
||||
- **Case #2** - best for **multi-product** supports (a given item never lives in two supports simultaneously). Reduces relocations during picking without pre-emptive defragmentation.
|
||||
|
||||
### 3.7 Route configuration
|
||||
|
||||
Every movement needs a route in EasyS between origin and destination. A single task `PIE → Miniload` typically generates **4 movements** — the WMS creates one task, but the routing table must allow every hop.
|
||||
Every movement needs a route in EasyS between origin and destination. A single task `PIE → Miniload` typically generates **4 movements** - the WMS creates one task, but the routing table must allow every hop.
|
||||
|
||||
> If no path exists, EasyWMS generates a **reject task** toward the reject station.
|
||||
|
||||
@@ -147,7 +147,7 @@ Multiple containers can sit on a TE/TS at once:
|
||||
|
||||
1. Size the table large enough physically
|
||||
2. Lay out containers in **Positions** (side by side) and **Stack** (one behind the other)
|
||||
3. **Logical X = 991** — except tables embedded in the rack, which inherit the replaced location's coordinates
|
||||
3. **Logical X = 991** - except tables embedded in the rack, which inherit the replaced location's coordinates
|
||||
|
||||
### 3.9 Multidirectional tables (LTM)
|
||||
|
||||
@@ -157,7 +157,7 @@ Set `routing options = 1` for every feeder conveyor allowed to deposit a contain
|
||||
|
||||
1. Add a conveyor with role **Picking**
|
||||
2. Create a **Workstation** to drive the station from SmartUI
|
||||
3. Define routes — where stock can arrive from, where it can leave to
|
||||
3. Define routes - where stock can arrive from, where it can leave to
|
||||
|
||||
Preparation table (TP/MP) routes:
|
||||
- **Manual** route from picking table → preparation tables
|
||||
@@ -172,7 +172,7 @@ The reject route lets the WMS redirect containers with no valid route.
|
||||
- Add a **VIRTUAL** route → floor zone so lost containers are moved off the simulation automatically
|
||||
- Reject routes render in **red**. Unlike normal routes, the red route gives the **task destination** (not the movement destination).
|
||||
|
||||
Different rejection reasons (`IdentError`) can point to different destinations — see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
|
||||
Different rejection reasons (`IdentError`) can point to different destinations - see [IdentErrorType](https://msscc.mecalux.com/documentation/Development/master/ES/apis/easywms/Domain/IdentErrorType.md).
|
||||
|
||||
## 4. SmartUI workstation configuration
|
||||
|
||||
@@ -183,14 +183,14 @@ Companion configuration once the EasyS layout is in place.
|
||||
Each preparation table is linked to a picking station. After picking confirmation, stock moves from the container to the chosen preparation table.
|
||||
|
||||
**Assignment mode:**
|
||||
- **Automatic** — WMS assigns the next order to a table
|
||||
- **Manual** — operator assigns via **Menu → Control → Picking-station assignment**
|
||||
- **Automatic** - WMS assigns the next order to a table
|
||||
- **Manual** - operator assigns via **Menu → Control → Picking-station assignment**
|
||||
|
||||
> ⚠️ In manual mode, **tasks do not generate until the shipping order is assigned to a table**.
|
||||
|
||||
To switch mode: **Menu → Control → Workstations** → select preparation table(s) → **Modify assignment mode**.
|
||||
|
||||
> ⚠️ The preparation table must have a route to the shipping dock of the order — otherwise tasks won't generate.
|
||||
> ⚠️ The preparation table must have a route to the shipping dock of the order - otherwise tasks won't generate.
|
||||
|
||||
### 4.2 Picking table max-concurrent orders
|
||||
|
||||
@@ -206,7 +206,7 @@ To cap how many orders a picking table can handle in parallel:
|
||||
2. Click **Start**
|
||||
3. Enter the WMS server IP → **Next**
|
||||
4. Uncheck **Generate simulation report** → click **Simulation 3D**
|
||||
5. Watch the Gateway log (`AllLog.log`) — lots of lines with no errors = connection OK
|
||||
5. Watch the Gateway log (`AllLog.log`) - lots of lines with no errors = connection OK
|
||||
|
||||
## 6. Inject a container at the PIE
|
||||
|
||||
@@ -218,9 +218,9 @@ To cap how many orders a picking table can handle in parallel:
|
||||
- Container Type: corresponding PLC Container Type
|
||||
- Weight
|
||||
- Height Type: corresponding PLC Height Type
|
||||
4. Click **Save** — a pallet/bin visibly moves on the conveyor
|
||||
4. Click **Save** - a pallet/bin visibly moves on the conveyor
|
||||
|
||||
> ⚠️ **Valid putaway strategies must exist** — even for empty containers. No valid location ⇒ reject.
|
||||
> ⚠️ **Valid putaway strategies must exist** - even for empty containers. No valid location ⇒ reject.
|
||||
|
||||
### Simulate a read error
|
||||
|
||||
@@ -228,7 +228,7 @@ Tab **Scripts** on the PIE → **Prepare event** → paste:
|
||||
```
|
||||
machine.Flags = "256";
|
||||
```
|
||||
Then inject the container. `256` = barcode error (see [GALILEO Integration — PIE flag table](../architecture/galileo-integration.md)).
|
||||
Then inject the container. `256` = barcode error (see [GALILEO Integration - PIE flag table](../architecture/galileo-integration.md)).
|
||||
|
||||
## 7. Extract a container from the miniload
|
||||
|
||||
@@ -258,7 +258,7 @@ On order release, the WMS:
|
||||
|
||||
Tasks are of type `pickingContainer`. After pick confirmation: **Store container** → **Liberate** to return the container to the miniload.
|
||||
|
||||
> Verify preparation-table config **before** launching an order — tasks won't generate if routes to the dock are missing.
|
||||
> Verify preparation-table config **before** launching an order - tasks won't generate if routes to the dock are missing.
|
||||
|
||||
## 8. Speed up simulation
|
||||
|
||||
@@ -287,7 +287,7 @@ Context.StationRoutes.Where(sr => sr.Manager.ToString() == "Galileo")
|
||||
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Side : 0,
|
||||
AisleNumber = sr.StationTo.AisleNumber
|
||||
})
|
||||
// union with StationFrom — full query on Confluence
|
||||
// union with StationFrom - full query on Confluence
|
||||
.OrderBy(sr => sr.StationType)
|
||||
.ThenBy(sr => sr.StationNumber)
|
||||
```
|
||||
@@ -315,16 +315,16 @@ More diagnostic steps: [Galileo Troubleshooting](galileo-troubleshooting.md).
|
||||
|
||||
## Common errors
|
||||
|
||||
- **Container injected at PIE but immediately rejected** — no valid putaway strategy covers the (container type, height type) combo, or no route exists to any storage location
|
||||
- **Tasks don't generate after order launch** — preparation table has no route to the dock, or assignment mode is Manual and the order isn't assigned
|
||||
- **Station stays loaded indefinitely in EasyS** — Manual Action ticked without running Liberate
|
||||
- **Gateway starts but no activity** — wrong `tenantCode` or `TokenUser` password; check Gateway log
|
||||
- **Connection refused from EasyS** — port 3000 not open, or Gateway service not started
|
||||
- **Container injected at PIE but immediately rejected** - no valid putaway strategy covers the (container type, height type) combo, or no route exists to any storage location
|
||||
- **Tasks don't generate after order launch** - preparation table has no route to the dock, or assignment mode is Manual and the order isn't assigned
|
||||
- **Station stays loaded indefinitely in EasyS** - Manual Action ticked without running Liberate
|
||||
- **Gateway starts but no activity** - wrong `tenantCode` or `TokenUser` password; check Gateway log
|
||||
- **Connection refused from EasyS** - port 3000 not open, or Gateway service not started
|
||||
|
||||
## Related
|
||||
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference
|
||||
- [Galileo Troubleshooting](galileo-troubleshooting.md) — log patterns, fault codes
|
||||
- [Robotics Project Lifecycle](robotics-project-lifecycle.md) — where simulation fits in the project plan
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference
|
||||
- [Galileo Troubleshooting](galileo-troubleshooting.md) - log patterns, fault codes
|
||||
- [Robotics Project Lifecycle](robotics-project-lifecycle.md) - where simulation fits in the project plan
|
||||
- [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md)
|
||||
- [Stations & Routes](../concepts/stations.md) · [Mechanical Elements](../concepts/mechanical-elements.md) · [Putaway](../concepts/putaway.md)
|
||||
|
||||
@@ -21,7 +21,7 @@ last_compiled: "2026-04-17"
|
||||
|
||||
How to read Gateway logs, interpret station / route updates, trace a container through a simulation or production run, and resolve the most common GALILEO faults (EndErrorCode=4, 1116 incorrect task, variator faults). Pair this page with [GALILEO Integration](../architecture/galileo-integration.md) for the protocol reference and [Galileo Simulation](galileo-simulation.md) for the bring-up procedure.
|
||||
|
||||
## 1. Gateway log — location & structure
|
||||
## 1. Gateway log - location & structure
|
||||
|
||||
`C:\ProgramData\Mecalux\EasyWMS Gateway 2015\Logs\AllLog.log`
|
||||
|
||||
@@ -46,7 +46,7 @@ Fields carried on each update:
|
||||
| **CurrentCount** | Trackings currently on the station |
|
||||
| **Aisle** | Aisle number bound to the station |
|
||||
|
||||
> The couple **StationType + StationNumber** is unique — always identify a station by that pair.
|
||||
> The couple **StationType + StationNumber** is unique - always identify a station by that pair.
|
||||
|
||||
### 1.2 Route update line
|
||||
|
||||
@@ -56,13 +56,13 @@ Fields carried on each update:
|
||||
| StationTypeDestination / StationNumberDestination | Destination station |
|
||||
| **Status** | `1` = free, `3` = full |
|
||||
|
||||
(Protocol also defines `0` = no comms, `2` = electromechanical fault — see [GALILEO Integration](../architecture/galileo-integration.md).)
|
||||
(Protocol also defines `0` = no comms, `2` = electromechanical fault - see [GALILEO Integration](../architecture/galileo-integration.md).)
|
||||
|
||||
### 1.3 Event, Search, End
|
||||
|
||||
- **Event** — typically a PIE event with barcode + weight + dimensions + container/height types
|
||||
- **Search** — a TK or conveyor asking for the next order
|
||||
- **End** — confirmation the container reached its destination (with an error code)
|
||||
- **Event** - typically a PIE event with barcode + weight + dimensions + container/height types
|
||||
- **Search** - a TK or conveyor asking for the next order
|
||||
- **End** - confirmation the container reached its destination (with an error code)
|
||||
|
||||
## 2. Trace a container in klogg
|
||||
|
||||
@@ -82,15 +82,15 @@ Two search patterns are usually enough to reconstruct a container's history.
|
||||
|
||||
This two-step pattern answers most "where is container X?" questions without paging through the whole log.
|
||||
|
||||
## 3. End error codes — diagnosis
|
||||
## 3. End error codes - diagnosis
|
||||
|
||||
| Code | Meaning | First action |
|
||||
|------|---------|--------------|
|
||||
| `0` | Movement complete | None — next movement generated |
|
||||
| `0` | Movement complete | None - next movement generated |
|
||||
| `1` | Deposit error | Inspect the destination location, relocation/reject task expected |
|
||||
| `2` | Extraction error | Inspect the source location, relocation/reject task expected |
|
||||
| `4` | Inconsistent order | WMS/GALILEO config mismatch — see section 3.1 |
|
||||
| `7` | Gauge error | Container fails dimensional check — routed to REAC / RECH |
|
||||
| `4` | Inconsistent order | WMS/GALILEO config mismatch - see section 3.1 |
|
||||
| `7` | Gauge error | Container fails dimensional check - routed to REAC / RECH |
|
||||
|
||||
### 3.1 EndErrorCode = 4 (most frequent)
|
||||
|
||||
@@ -103,14 +103,14 @@ GALILEO did not understand the order. Root cause is **always** a configuration d
|
||||
- Two containers planned to cross paths (impossible movement)
|
||||
- Coordinate system discrepancy between sides of the entry table vs the aisle
|
||||
|
||||
**Resolution — 4 steps:**
|
||||
**Resolution - 4 steps:**
|
||||
|
||||
1. Grab the frame sent to GALILEO from the Gateway log (Station types, numbers, coordinates, container/height type)
|
||||
2. Open the GALILEO program: `C:\<NomDuClient>\Programme\<installation>.mgp` (double-click to launch)
|
||||
3. Compare the station list between GALILEO and EasyS — aisle, allowed types, X/Y — line by line
|
||||
4. Use the station query shipped with [Galileo Simulation — §9.1](galileo-simulation.md) to dump the WMS-side view
|
||||
3. Compare the station list between GALILEO and EasyS - aisle, allowed types, X/Y - line by line
|
||||
4. Use the station query shipped with [Galileo Simulation - §9.1](galileo-simulation.md) to dump the WMS-side view
|
||||
|
||||
If you change anything on the GALILEO side, also sync the change in EasyS (and vice versa) — the two systems must stay in lock-step.
|
||||
If you change anything on the GALILEO side, also sync the change in EasyS (and vice versa) - the two systems must stay in lock-step.
|
||||
|
||||
## 4. GALILEO fault codes
|
||||
|
||||
@@ -119,16 +119,16 @@ Faults reported on the GALILEO SCADA / Automation Dashboard. See [Automation Das
|
||||
| Code | Name | Typical causes |
|
||||
|------|------|----------------|
|
||||
| **1116** | Incorrect task CU1 | Location locked on GALILEO but not on EasyWMS (or vice versa); location exists in EasyWMS but not in GALILEO; same location has different allowed container types on each side; WMS asks to deposit on the left rack while the container sits on the right fork of the miniload (and vice versa) |
|
||||
| **1201** | Variator fault X | — (variator hardware fault on axis X) |
|
||||
| **1201** | Variator fault X | - (variator hardware fault on axis X) |
|
||||
| **1291** | Unreferenced SM302 card on the variator | Warning only |
|
||||
|
||||
Fault 1116 is the configuration-drift counterpart of `EndErrorCode=4` at the automation layer — same root cause, different reporting surface.
|
||||
Fault 1116 is the configuration-drift counterpart of `EndErrorCode=4` at the automation layer - same root cause, different reporting surface.
|
||||
|
||||
## 5. Change the WMS address inside GALILEO
|
||||
|
||||
When the WMS server IP or DNS changes (migration, VM rename, network reconfig), the GALILEO side must be updated so the PLC can reach the new Gateway.
|
||||
|
||||
> ⚠️ The Confluence page for this procedure contains only screenshots (no extractable text). Refer to [Confluence — Changer l'adresse du WMS dans GALILEO](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552) for the step-by-step screen walkthrough.
|
||||
> ⚠️ The Confluence page for this procedure contains only screenshots (no extractable text). Refer to [Confluence - Changer l'adresse du WMS dans GALILEO](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000756076552) for the step-by-step screen walkthrough.
|
||||
|
||||
High-level: update the WMS IP / hostname inside the GALILEO program configuration (the `.mgp` file under `C:\<NomDuClient>\Programme\`) and restart the GALILEO runtime. Then verify the Gateway log picks up the new connection.
|
||||
|
||||
@@ -136,19 +136,19 @@ High-level: update the WMS IP / hostname inside the GALILEO program configuratio
|
||||
|
||||
Before opening a ticket or calling Support:
|
||||
|
||||
- [ ] Gateway service (`EasyWMSGateway2015`) is **Running**
|
||||
- [ ] `AllLog.log` shows recent traffic (not frozen, no error spike)
|
||||
- [ ] Port 3000 is open on the WMS host (inbound + outbound)
|
||||
- [ ] `tenantCode` and `TokenUser` in `MainObject.config` match the target WMS
|
||||
- [ ] The specific (StationType, StationNumber) pair exists on both sides with identical parameters
|
||||
- [ ] Allowed container types + PLC Height Type couple match on both sides
|
||||
- [ ] No untracked containers stranded on blind conveyors (LBC, LRL — see [Mechanical Elements](../concepts/mechanical-elements.md))
|
||||
- [ ] Automation Dashboard fault report consulted to correlate with machine-level faults
|
||||
- ☐ Gateway service (`EasyWMSGateway2015`) is **Running**
|
||||
- ☐ `AllLog.log` shows recent traffic (not frozen, no error spike)
|
||||
- ☐ Port 3000 is open on the WMS host (inbound + outbound)
|
||||
- ☐ `tenantCode` and `TokenUser` in `MainObject.config` match the target WMS
|
||||
- ☐ The specific (StationType, StationNumber) pair exists on both sides with identical parameters
|
||||
- ☐ Allowed container types + PLC Height Type couple match on both sides
|
||||
- ☐ No untracked containers stranded on blind conveyors (LBC, LRL - see [Mechanical Elements](../concepts/mechanical-elements.md))
|
||||
- ☐ Automation Dashboard fault report consulted to correlate with machine-level faults
|
||||
|
||||
## Related
|
||||
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference, workflows, command/event catalogue
|
||||
- [Galileo Simulation](galileo-simulation.md) — EasyS bring-up, station sync query
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference, workflows, command/event catalogue
|
||||
- [Galileo Simulation](galileo-simulation.md) - EasyS bring-up, station sync query
|
||||
- [General Troubleshooting Guide](troubleshooting.md)
|
||||
- [Stations & Routes](../concepts/stations.md) · [Mechanical Elements](../concepts/mechanical-elements.md)
|
||||
- [Automation Dashboard](../modules/automation-dashboard.md) — fault reporting UI
|
||||
- [Automation Dashboard](../modules/automation-dashboard.md) - fault reporting UI
|
||||
|
||||
@@ -16,12 +16,12 @@ last_compiled: "2026-04-17"
|
||||
|
||||
Stratégie de gestion **par phase de projet** des branches Git pour les projets EasyWMS France : qui fait quoi, à quel moment, sur quelle branche. Cette page complète :
|
||||
|
||||
- [development-methodology](development-methodology.md) — vue d'ensemble (master / développement / post-production)
|
||||
- [git-workflow](git-workflow.md) — procédure opérationnelle Git Flow (CLI / SourceTree)
|
||||
- [development-methodology](development-methodology.md) - vue d'ensemble (master / développement / post-production)
|
||||
- [git-workflow](git-workflow.md) - procédure opérationnelle Git Flow (CLI / SourceTree)
|
||||
|
||||
…en explicitant les **règles de gouvernance** entre les acteurs (Dev, CdP, Support, TMA) au fil du cycle de vie : **Développement → Mise en service (MEP) → Hypercare → TLM (Tierce Maintenance) → TMA (Tierce Maintenance Applicative)**.
|
||||
|
||||
Source : Confluence EasyWMS France — *Gestion du GIT* (v1, 27/02/2024).
|
||||
Source : Confluence EasyWMS France - *Gestion du GIT* (v1, 27/02/2024).
|
||||
|
||||
## Acteurs
|
||||
|
||||
@@ -90,9 +90,9 @@ Outil : **Git Flow dans Sourcetree**.
|
||||
|
||||
## 4. Pendant la TLM et la TMA
|
||||
|
||||
### a. Branches `hotfix` — équipe Support
|
||||
### a. Branches `hotfix` - équipe Support
|
||||
|
||||
**Cas 1 — Modifications longues / conséquentes ou testées sur intégration d'abord :**
|
||||
**Cas 1 - Modifications longues / conséquentes ou testées sur intégration d'abord :**
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|---|---|
|
||||
@@ -100,14 +100,14 @@ Outil : **Git Flow dans Sourcetree**.
|
||||
| 2 | Support | Merger `hotfix` → `master` à la livraison |
|
||||
| 3 | Support | **Prévenir l'équipe TMA** qu'une livraison a eu lieu *(pour mise à jour des branches `release` en cours)* |
|
||||
|
||||
**Cas 2 — Modifications directes en production :**
|
||||
**Cas 2 - Modifications directes en production :**
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|---|---|
|
||||
| 1 | Support | **Exporter la production dans `master`** |
|
||||
| 2 | Support | **Prévenir l'équipe TMA** qu'une livraison a eu lieu |
|
||||
|
||||
### b. Branches `release` — équipe TMA
|
||||
### b. Branches `release` - équipe TMA
|
||||
|
||||
| # | Acteur | Action |
|
||||
|---|---|---|
|
||||
@@ -123,7 +123,7 @@ Outil : **Git Flow dans Sourcetree**.
|
||||
|
||||
> ⚠️ Communication **bidirectionnelle obligatoire** sur les livraisons :
|
||||
> - Dev ↔ CdP (pendant le projet)
|
||||
> - **Support ↔ TMA** (pendant TLM/TMA — chaque livraison de l'un impose un re-merge de l'autre)
|
||||
> - **Support ↔ TMA** (pendant TLM/TMA - chaque livraison de l'un impose un re-merge de l'autre)
|
||||
>
|
||||
> Une livraison non communiquée provoque des conflits Git lourds + risque de régressions en prod.
|
||||
|
||||
@@ -152,6 +152,6 @@ master ────────────────────────
|
||||
|
||||
## Related
|
||||
|
||||
- [Development Methodology (Custom Apps)](development-methodology.md) — stratégie haut niveau master/développement/post-production
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) — commandes Git Flow CLI + SourceTree (le "comment" opérationnel)
|
||||
- [Deploy Test Application](deploy-test-application.md) — création du tag `<TRIGRAMME>-V<N>` et déploiement de la livraison en test
|
||||
- [Development Methodology (Custom Apps)](development-methodology.md) - stratégie haut niveau master/développement/post-production
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) - commandes Git Flow CLI + SourceTree (le "comment" opérationnel)
|
||||
- [Deploy Test Application](deploy-test-application.md) - création du tag `<TRIGRAMME>-V<N>` et déploiement de la livraison en test
|
||||
|
||||
@@ -30,7 +30,7 @@ Workflow **Git Flow** appliqué aux projets EasyWMS France. Git Flow est une ext
|
||||
|
||||
La gestion est expliquée en parallèle via **invite de commande (CLI)** et **[SourceTree](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000088854571)** (configuré en anglais).
|
||||
|
||||
Source : Confluence EasyWMS France — *Gestion des versions du projet avec GIT* (v27, 22/08/2025).
|
||||
Source : Confluence EasyWMS France - *Gestion des versions du projet avec GIT* (v27, 22/08/2025).
|
||||
|
||||
### Ressources externes
|
||||
|
||||
@@ -90,7 +90,7 @@ git flow feature start <nom de la feature>
|
||||
|
||||
### Déployer la VM sur la nouvelle branche
|
||||
|
||||
1. Appliquer le point de contrôle **"DEPLOY 0"** sur la VM (cf. [vm-installation](vm-installation.md#7--point-de-contrôle-deploy-0))
|
||||
1. Appliquer le point de contrôle **"DEPLOY 0"** sur la VM (cf. [vm-installation](vm-installation.md#7-point-de-contrôle-deploy-0))
|
||||
2. Déployer la branche : cf. [deployment-existing-app](deployment-existing-app.md)
|
||||
|
||||
> Si une pop-up de connexion apparaît sur SmartUI après déploiement : [procédure dédiée Confluence](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000144789544)
|
||||
@@ -99,11 +99,11 @@ Vous êtes prêt à commencer vos développements. ✅
|
||||
|
||||
## 3. Commit de vos modifications
|
||||
|
||||
### Étape préalable — exporter les modifications
|
||||
### Étape préalable - exporter les modifications
|
||||
|
||||
Avant tout commit, exporter **tout ce qui a été modifié** :
|
||||
|
||||
1. **Custom app** → cf. [custom-application-management — Export](custom-application-management.md#export)
|
||||
1. **Custom app** → cf. [custom-application-management - Export](custom-application-management.md#export)
|
||||
2. **Paramètres / config WMS modifiés** → export datas via **[uGNA](ugna-data-export.md)** (procédure complète avec liste des entités et erreurs droits)
|
||||
3. **Fichiers BOO du GNA modifiés** → exécuter [`GNAGetDataForGit.ps1`](gna-services-license.md#sauvegarder-la-configuration-sur-le-git)
|
||||
|
||||
@@ -132,7 +132,7 @@ git push
|
||||
|
||||
> ℹ️ Les fichiers générés par l'export de la custom app sont **séparés en plusieurs fichiers** pour un même élément (workflow, source C#, DESIGN…). Bien prendre **tous** les fichiers portant le nom de l'élément modifié.
|
||||
|
||||
> ⚠️ **Règle absolue : commit et push ses développements tous les soirs avant de quitter les bureaux** — évite toute perte (perte/vol/casse du PC).
|
||||
> ⚠️ **Règle absolue : commit et push ses développements tous les soirs avant de quitter les bureaux** - évite toute perte (perte/vol/casse du PC).
|
||||
|
||||
## 4. Fin de la tâche de développement
|
||||
|
||||
@@ -177,10 +177,10 @@ git rebase --continue
|
||||
```
|
||||
|
||||
**SourceTree :**
|
||||
1. **Ne pas faire de commit** — uniquement **"stage"** les fichiers résolus
|
||||
1. **Ne pas faire de commit** - uniquement **"stage"** les fichiers résolus
|
||||
2. **"Continue Rebase"**
|
||||
3. Répéter pour chaque commit de `develop`
|
||||
4. Recommencer la clôture de la feature — cette fois **sans cocher "Rebase"**
|
||||
4. Recommencer la clôture de la feature - cette fois **sans cocher "Rebase"**
|
||||
|
||||
### 4.4 Mettre à jour Jira
|
||||
|
||||
@@ -188,11 +188,11 @@ Passer le ticket à **"Revue de code"**.
|
||||
|
||||
## Checklist journalière
|
||||
|
||||
- [ ] `git pull` en début de journée sur votre branche
|
||||
- [ ] Commits petits et explicites tout au long de la journée
|
||||
- [ ] **Avant commit** : export custom app + uGNA + GNA (si concerné)
|
||||
- [ ] **Soir** : tous les commits poussés sur le remote (**règle absolue**)
|
||||
- [ ] Avant clôture : `develop` à jour + rebase réussi
|
||||
- ☐ `git pull` en début de journée sur votre branche
|
||||
- ☐ Commits petits et explicites tout au long de la journée
|
||||
- ☐ **Avant commit** : export custom app + uGNA + GNA (si concerné)
|
||||
- ☐ **Soir** : tous les commits poussés sur le remote (**règle absolue**)
|
||||
- ☐ Avant clôture : `develop` à jour + rebase réussi
|
||||
|
||||
## Parameters / Branches Git Flow
|
||||
|
||||
@@ -202,7 +202,7 @@ Passer le ticket à **"Revue de code"**.
|
||||
| Bugfix | `bugfix/` | `develop` | `develop` | Corrections de bugs sur le développement en cours |
|
||||
| Release | `release/` | `develop` | `master` + `develop` | Préparation d'une release |
|
||||
| Hotfix | `hotfix/` | `master` | `master` + `develop` | Correctifs urgents en production |
|
||||
| Support | `support/` | `master` | — | Maintien d'une version antérieure |
|
||||
| Support | `support/` | `master` | - | Maintien d'une version antérieure |
|
||||
|
||||
## Common errors
|
||||
|
||||
@@ -216,12 +216,12 @@ Passer le ticket à **"Revue de code"**.
|
||||
|
||||
## Related
|
||||
|
||||
- [Development Methodology](development-methodology.md) — cadre général (branches `master`/`développement`/`post-production`, phases dev/test/post-prod)
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) — gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA
|
||||
- [SSH Keys Setup (MSSCODE & Sourcetree)](ssh-keys-setup.md) — clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE
|
||||
- [Custom Application Management](custom-application-management.md) — export/import systématique avant commit
|
||||
- [uGNA Data Export](ugna-data-export.md) — export config WMS via `uGNAConsole.exe -Z:` (étape pré-commit)
|
||||
- [Code Review Process](code-review-process.md) — revue Code/Fonctionnel/Documentation avant `Finish Feature`
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — déploiement après pull ou changement de branche
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) — figer un commit pour démo / debug
|
||||
- [GNA, Services & License](gna-services-license.md) — sauvegarde GIT des scripts BOO avant commit
|
||||
- [Development Methodology](development-methodology.md) - cadre général (branches `master`/`développement`/`post-production`, phases dev/test/post-prod)
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) - gouvernance par phase de projet (Dev / MEP / Hypercare / TLM / TMA), rôles Dev/CdP/Support/TMA
|
||||
- [SSH Keys Setup (MSSCODE & Sourcetree)](ssh-keys-setup.md) - clé SSH ed25519 pour ne plus saisir les identifiants MSSCODE
|
||||
- [Custom Application Management](custom-application-management.md) - export/import systématique avant commit
|
||||
- [uGNA Data Export](ugna-data-export.md) - export config WMS via `uGNAConsole.exe -Z:` (étape pré-commit)
|
||||
- [Code Review Process](code-review-process.md) - revue Code/Fonctionnel/Documentation avant `Finish Feature`
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - déploiement après pull ou changement de branche
|
||||
- [Deploy Specific Commit](deployment-specific-commit.md) - figer un commit pour démo / debug
|
||||
- [GNA, Services & License](gna-services-license.md) - sauvegarde GIT des scripts BOO avant commit
|
||||
|
||||
@@ -20,13 +20,13 @@ last_compiled: "2026-04-17"
|
||||
|
||||
Procédures d'installation et de gestion des **services adjacents** au WMS sur une VM de développement :
|
||||
|
||||
- **GNA** (Generic Notification Applications) — service de messagerie ERP ↔ WMS : sauvegarde GIT des scripts/XSD + réinstallation sur VM
|
||||
- **Label Printer** — service d'impression d'étiquettes
|
||||
- **Licence WMS** (EasySTS) — demande / import de la licence projet pour que la VM fonctionne au-delà de 7 jours
|
||||
- **GNA** (Generic Notification Applications) - service de messagerie ERP ↔ WMS : sauvegarde GIT des scripts/XSD + réinstallation sur VM
|
||||
- **Label Printer** - service d'impression d'étiquettes
|
||||
- **Licence WMS** (EasySTS) - demande / import de la licence projet pour que la VM fonctionne au-delà de 7 jours
|
||||
|
||||
Le GNA est le composant qui porte la communication ERP (messages tels que `ROR`, `SOR`, `STV`, `SOF`…) — voir [erp-interface](../concepts/erp-interface.md) pour la sémantique fonctionnelle des messages.
|
||||
Le GNA est le composant qui porte la communication ERP (messages tels que `ROR`, `SOR`, `STV`, `SOF`…) - voir [erp-interface](../concepts/erp-interface.md) pour la sémantique fonctionnelle des messages.
|
||||
|
||||
Source : Confluence EasyWMS France — *Installation Services et Licence WMS* (v19, 15/04/2025).
|
||||
Source : Confluence EasyWMS France - *Installation Services et Licence WMS* (v19, 15/04/2025).
|
||||
|
||||
## Service GNA
|
||||
|
||||
@@ -50,9 +50,9 @@ Le script **exporte les fichiers nécessaires à l'installation du GNA** (script
|
||||
|
||||
> ⚠️ Les XSD sont **composés à l'installation** à partir des fichiers du dossier `XSD_Source` de votre GNA.
|
||||
>
|
||||
> **Ne pas copier directement le XML du dossier `XSD` de votre GNA** — il serait pris comme "source" et recomposé avec les `XSD_Source` des autres applications, entraînant des **duplications de lignes**.
|
||||
> **Ne pas copier directement le XML du dossier `XSD` de votre GNA** - il serait pris comme "source" et recomposé avec les `XSD_Source` des autres applications, entraînant des **duplications de lignes**.
|
||||
|
||||
#### Exemple — composition du fichier SOF02
|
||||
#### Exemple - composition du fichier SOF02
|
||||
|
||||
Le fichier final `C:\ProgramData\Mecalux\GnaService2015\XSD\SOF02.xsd` peut être composé de :
|
||||
|
||||
@@ -66,7 +66,7 @@ Le fichier final `C:\ProgramData\Mecalux\GnaService2015\XSD\SOF02.xsd` peut êtr
|
||||
|
||||
> ⚠️ Avec les nouvelles versions des scripts (GNA installé lors du deploy depuis le repository), le GNA **n'est plus installé au même endroit** qu'auparavant. Le script peut planter car il ne trouve pas les dossiers GNA.
|
||||
|
||||
**Solution** — modifier les chemins dans **`responses.xml`** du dossier `InstallApplications` :
|
||||
**Solution** - modifier les chemins dans **`responses.xml`** du dossier `InstallApplications` :
|
||||
|
||||
```xml
|
||||
<!-- Ancien chemin -->
|
||||
@@ -86,7 +86,7 @@ Récupérer le dossier GNA créé par le script et l'ajouter au GIT dans :
|
||||
\services\GNA
|
||||
```
|
||||
|
||||
Puis commit + push (cf. [git-workflow](git-workflow.md#3--commit-de-vos-modifications)).
|
||||
Puis commit + push (cf. [git-workflow](git-workflow.md#3-commit-de-vos-modifications)).
|
||||
|
||||
### Réinstallation d'un GNA
|
||||
|
||||
@@ -106,7 +106,7 @@ Procédure à suivre si le GNA a déjà été installé sur la VM et doit être
|
||||
```
|
||||
Choisir l'option **"complete"**.
|
||||
|
||||
> En cas d'erreur : voir Confluence *Installation GNA — Exécution de l'installation*.
|
||||
> En cas d'erreur : voir Confluence *Installation GNA - Exécution de l'installation*.
|
||||
|
||||
## Service Label Printer
|
||||
|
||||
@@ -140,11 +140,11 @@ La date de validité est mise à jour dans **EasySTS**.
|
||||
|
||||
## Règles pratiques
|
||||
|
||||
- **GIT commit du dossier `\services\GNA`** à chaque modification de script BOO — sinon les autres devs travaillent sur une version obsolète.
|
||||
- **Ne jamais pousser le XML composé** de `XSD/` — uniquement les fichiers de `XSD_Source` (sinon duplications).
|
||||
- **GIT commit du dossier `\services\GNA`** à chaque modification de script BOO - sinon les autres devs travaillent sur une version obsolète.
|
||||
- **Ne jamais pousser le XML composé** de `XSD/` - uniquement les fichiers de `XSD_Source` (sinon duplications).
|
||||
- **Vérifier les chemins `responses.xml`** si le script d'export plante (nouvelle location `C:\Program Files\...`).
|
||||
- **Toujours dézipper `InstallApplication.zip` frais** lors d'une réinstallation — ne pas réutiliser un dossier existant qui pourrait mélanger les versions.
|
||||
- **Licence à renouveler avant expiration** — sinon WMS inutilisable sur la VM.
|
||||
- **Toujours dézipper `InstallApplication.zip` frais** lors d'une réinstallation - ne pas réutiliser un dossier existant qui pourrait mélanger les versions.
|
||||
- **Licence à renouveler avant expiration** - sinon WMS inutilisable sur la VM.
|
||||
|
||||
## Common errors
|
||||
|
||||
@@ -157,8 +157,8 @@ La date de validité est mise à jour dans **EasySTS**.
|
||||
|
||||
## Related
|
||||
|
||||
- [System Architecture Overview](../architecture/overview.md) — architecture IIS / services WMS
|
||||
- [ERP Interface](../concepts/erp-interface.md) — messages ERP portés par le GNA (ROR/SOR/SOF/STV/etc.)
|
||||
- [First Deployment](first-deployment.md) — déploiement initial (GNA inclus dans `EnabledModules`)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — redéploiement après mise à jour GNA
|
||||
- [Git Workflow](git-workflow.md) — commit/push du dossier `\services\GNA` après modification de scripts BOO
|
||||
- [System Architecture Overview](../architecture/overview.md) - architecture IIS / services WMS
|
||||
- [ERP Interface](../concepts/erp-interface.md) - messages ERP portés par le GNA (ROR/SOR/SOF/STV/etc.)
|
||||
- [First Deployment](first-deployment.md) - déploiement initial (GNA inclus dans `EnabledModules`)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - redéploiement après mise à jour GNA
|
||||
- [Git Workflow](git-workflow.md) - commit/push du dossier `\services\GNA` après modification de scripts BOO
|
||||
|
||||
@@ -23,24 +23,24 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
Robotics projects — installations with mechanized hardware (miniload, TK, conveyors, APS, AGV…) — require tighter coordination than pure-software projects because physical installation, electrical work and IT integration run in parallel. This page covers the organizational roles, reference documents, planning artifacts, and the station-test milestone that validates the WMS ↔ GALILEO configuration before go-live.
|
||||
Robotics projects - installations with mechanized hardware (miniload, TK, conveyors, APS, AGV…) - require tighter coordination than pure-software projects because physical installation, electrical work and IT integration run in parallel. This page covers the organizational roles, reference documents, planning artifacts, and the station-test milestone that validates the WMS ↔ GALILEO configuration before go-live.
|
||||
|
||||
## 1. Project organization
|
||||
|
||||
A robotics project pulls in multiple Mecalux stakeholders:
|
||||
|
||||
- **Chef de chantier** — site supervisor for the mechanical build
|
||||
- **Chef de projet IT** — IT lead (WMS + automation integration)
|
||||
- **Responsable électricité** — electrical lead
|
||||
- **Responsable de projet** — master coordinator who aligns the above, owns the schedule, and guarantees everyone has the right information at the right time
|
||||
- **Chef de chantier** - site supervisor for the mechanical build
|
||||
- **Chef de projet IT** - IT lead (WMS + automation integration)
|
||||
- **Responsable électricité** - electrical lead
|
||||
- **Responsable de projet** - master coordinator who aligns the above, owns the schedule, and guarantees everyone has the right information at the right time
|
||||
|
||||
The **Responsable de projet** is the single point of escalation; without them, gaps between disciplines (e.g. the rack is installed but the DTR has not been validated) lead to slippage.
|
||||
|
||||
> The canonical organisational diagram for a robotics project is on [Confluence — Organisation d'un projet Robotique](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874).
|
||||
> The canonical organisational diagram for a robotics project is on [Confluence - Organisation d'un projet Robotique](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000434425874).
|
||||
|
||||
## 2. DTR — Document Technique de Référence
|
||||
## 2. DTR - Document Technique de Référence
|
||||
|
||||
The **DTR (Document Technique de Référence)** lists every technical element required for an automated installation — hardware, IP addresses, services, accounts — along with the **responsibility split between Mecalux and the client**.
|
||||
The **DTR (Document Technique de Référence)** lists every technical element required for an automated installation - hardware, IP addresses, services, accounts - along with the **responsibility split between Mecalux and the client**.
|
||||
|
||||
The DTR answers "who provides what and by when":
|
||||
- WMS server specs and OS
|
||||
@@ -49,23 +49,23 @@ The DTR answers "who provides what and by when":
|
||||
- Services (Active Directory, DNS, NTP, SMTP)
|
||||
- Physical access and ports opened between segments
|
||||
|
||||
The DTR template lives on [Confluence — DTR configuration réseau et matériel](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980) as a table format. Fill a copy per project; track outstanding client deliverables in Jira.
|
||||
The DTR template lives on [Confluence - DTR configuration réseau et matériel](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000562515980) as a table format. Fill a copy per project; track outstanding client deliverables in Jira.
|
||||
|
||||
## 3. Planning (Miniload installation)
|
||||
|
||||
Two reference plannings used on every miniload project:
|
||||
|
||||
1. **Global installation planning** — overview of all phases (civil works → rack install → electrical → PLC commissioning → WMS integration → tests → go-live)
|
||||
2. **IT ROB planning** — the slice owned by the IT Robotics team (VM install, WMS deploy, EasyS configuration, Gateway, station tests, Hypercare)
|
||||
1. **Global installation planning** - overview of all phases (civil works → rack install → electrical → PLC commissioning → WMS integration → tests → go-live)
|
||||
2. **IT ROB planning** - the slice owned by the IT Robotics team (VM install, WMS deploy, EasyS configuration, Gateway, station tests, Hypercare)
|
||||
|
||||
Both plannings live as Gantt images on [Confluence — Planning Installation Miniload](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Copy the Gantt at project kick-off and adjust dates to site reality.
|
||||
Both plannings live as Gantt images on [Confluence - Planning Installation Miniload](https://easywmsfrance.atlassian.net/wiki/spaces/EF/pages/3000567955477). Copy the Gantt at project kick-off and adjust dates to site reality.
|
||||
|
||||
## 4. Reference documentation
|
||||
|
||||
| Document | Purpose | Location |
|
||||
|----------|---------|----------|
|
||||
| **Control_Communications_Interface_EN_GB.pdf** | All station types, event types, PIE flags | [MSSCC Automation docs](https://msscc.mecalux.com/documentation/Automation/master/ES/Documents/GalileoAWS/Control_Communications_Interface_EN_GB.pdf) |
|
||||
| **EasyWMSGateway_ControlInterface_EN.pdf** | Frame structure (low-level — used when a frame translation looks wrong) | [MSSCC services docs](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) |
|
||||
| **EasyWMSGateway_ControlInterface_EN.pdf** | Frame structure (low-level - used when a frame translation looks wrong) | [MSSCC services docs](https://msscc.mecalux.com/documentation/documentation/master/ES/docs_downloads/services/docs/EasyWMSGateway_ControlInterface_EN.pdf) |
|
||||
| **Stations index** | Station-specific behaviours and quirks | [MSSCC Stations index](https://msscc.mecalux.com/documentation/documentation/master/EN/areas/layout/stations/index.md) |
|
||||
|
||||
Use them as the source of truth when writing the functional spec / interface document with GALILEO.
|
||||
@@ -105,7 +105,7 @@ Context.StationRoutes.Where(sr => sr.Manager.ToString() == "Galileo")
|
||||
? sr.StationTo.RealLocations.FirstOrDefault().LogicalCoordinate.Side : 0,
|
||||
AisleNumber = sr.StationTo.AisleNumber
|
||||
})
|
||||
// union with StationFrom — see full query on Confluence
|
||||
// union with StationFrom - see full query on Confluence
|
||||
.OrderBy(sr => sr.StationType)
|
||||
.ThenBy(sr => sr.StationNumber)
|
||||
```
|
||||
@@ -128,22 +128,22 @@ Verify during simulation by temporarily saturating each route and confirming the
|
||||
|
||||
Consolidated checklist merging what each phase must deliver:
|
||||
|
||||
- [ ] DTR signed by client and Mecalux (hardware, IPs, services provisioned)
|
||||
- [ ] VM installed, joined to the domain, reachable via VPN (see [VM Installation](vm-installation.md) / [VM Network Routing](vm-network-routing.md))
|
||||
- [ ] EasyWMS deployed (see [First Deployment](first-deployment.md))
|
||||
- [ ] EasyS layout matches the execution plan (racks, stations, routes, PLC Types)
|
||||
- [ ] Gateway installed, `tenantCode` + `TokenUser` configured, port 3000 open
|
||||
- [ ] Station test query matches GALILEO `.mgp` station list
|
||||
- [ ] PLC Container Type / PLC Height Type coupling validated in simulation
|
||||
- [ ] "Full" route checks passed (CME→TE, PKE→PK, ET→PS)
|
||||
- [ ] End-to-end flows validated in EasyS (PIE → Miniload → PK → PS)
|
||||
- [ ] Reject route + floor virtual route configured (no lost container)
|
||||
- [ ] Automation Dashboard wired up with the client's monitoring (see [Automation Dashboard](../modules/automation-dashboard.md))
|
||||
- ☐ DTR signed by client and Mecalux (hardware, IPs, services provisioned)
|
||||
- ☐ VM installed, joined to the domain, reachable via VPN (see [VM Installation](vm-installation.md) / [VM Network Routing](vm-network-routing.md))
|
||||
- ☐ EasyWMS deployed (see [First Deployment](first-deployment.md))
|
||||
- ☐ EasyS layout matches the execution plan (racks, stations, routes, PLC Types)
|
||||
- ☐ Gateway installed, `tenantCode` + `TokenUser` configured, port 3000 open
|
||||
- ☐ Station test query matches GALILEO `.mgp` station list
|
||||
- ☐ PLC Container Type / PLC Height Type coupling validated in simulation
|
||||
- ☐ "Full" route checks passed (CME→TE, PKE→PK, ET→PS)
|
||||
- ☐ End-to-end flows validated in EasyS (PIE → Miniload → PK → PS)
|
||||
- ☐ Reject route + floor virtual route configured (no lost container)
|
||||
- ☐ Automation Dashboard wired up with the client's monitoring (see [Automation Dashboard](../modules/automation-dashboard.md))
|
||||
|
||||
## Related
|
||||
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) — protocol reference
|
||||
- [Galileo Simulation](galileo-simulation.md) — EasyS bring-up, PIE injection, station sync
|
||||
- [Galileo Troubleshooting](galileo-troubleshooting.md) — log analysis, faults
|
||||
- [GALILEO Integration](../architecture/galileo-integration.md) - protocol reference
|
||||
- [Galileo Simulation](galileo-simulation.md) - EasyS bring-up, PIE injection, station sync
|
||||
- [Galileo Troubleshooting](galileo-troubleshooting.md) - log analysis, faults
|
||||
- [VM Installation](vm-installation.md) · [VM Network Routing](vm-network-routing.md) · [First Deployment](first-deployment.md)
|
||||
- [Mechanical Elements](../concepts/mechanical-elements.md) · [Stations & Routes](../concepts/stations.md)
|
||||
|
||||
@@ -13,9 +13,9 @@ last_compiled: "2026-04-17"
|
||||
|
||||
## Overview
|
||||
|
||||
Procédure interne Mecalux EasyWMS France pour générer une **clé SSH ed25519**, l'enregistrer sur **MSSCODE** (le Gitea interne Mecalux) et la connecter à **Sourcetree**. Une fois en place, Sourcetree n'a plus à demander les identifiants MSSCODE à chaque opération Git — seul le mot de passe de la clé SSH est exigé à l'ouverture de Sourcetree.
|
||||
Procédure interne Mecalux EasyWMS France pour générer une **clé SSH ed25519**, l'enregistrer sur **MSSCODE** (le Gitea interne Mecalux) et la connecter à **Sourcetree**. Une fois en place, Sourcetree n'a plus à demander les identifiants MSSCODE à chaque opération Git - seul le mot de passe de la clé SSH est exigé à l'ouverture de Sourcetree.
|
||||
|
||||
Source : Confluence EasyWMS France — *Configuration d'une clé SSH pour MSSCODE et Sourcetree* (v2, 28/01/2026).
|
||||
Source : Confluence EasyWMS France - *Configuration d'une clé SSH pour MSSCODE et Sourcetree* (v2, 28/01/2026).
|
||||
|
||||
## 1. Génération de la clé SSH
|
||||
|
||||
@@ -36,8 +36,8 @@ ssh-keygen -t ed25519 -C "your_email@example.com"
|
||||
> ⚠️ Le mot de passe de la clé est **unique et non modifiable**. En cas d'oubli, il faut **régénérer une nouvelle paire de clés**. Une clé sans mot de passe est techniquement possible mais **fortement déconseillée**.
|
||||
|
||||
Deux fichiers sont créés dans `C:\Users\<user>\.ssh\` :
|
||||
- `id_ed25519` — clé **privée** (à ne jamais partager)
|
||||
- `id_ed25519.pub` — clé **publique** (à enregistrer sur MSSCODE)
|
||||
- `id_ed25519` - clé **privée** (à ne jamais partager)
|
||||
- `id_ed25519.pub` - clé **publique** (à enregistrer sur MSSCODE)
|
||||
|
||||
## 2. Enregistrement de la clé sur MSSCODE
|
||||
|
||||
@@ -87,5 +87,5 @@ Le lien SSH est exposé sur la page du dépôt MSSCODE (bouton "Code" / "Clone"
|
||||
|
||||
## Related
|
||||
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) — opérations Git quotidiennes effectuées avec cette clé
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) — cycle des branches Git par phase de projet
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) - opérations Git quotidiennes effectuées avec cette clé
|
||||
- [Git Branch Lifecycle](git-branch-lifecycle.md) - cycle des branches Git par phase de projet
|
||||
|
||||
@@ -49,11 +49,11 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
- **Cause:** Order code unknown to WMS or ROR message not yet received from ERP.
|
||||
- **Solution:** Enable `ALLOW_CREATE_RECEPTION` to allow blind receipt creation; or have ERP resend the ROR message first.
|
||||
|
||||
### ASN container rejected at PIE — order doesn't exist
|
||||
### ASN container rejected at PIE - order doesn't exist
|
||||
- **Cause:** The receipt order referenced in the ASN message has not yet arrived in WMS.
|
||||
- **Solution:** If `USE_EXCLUSIVE_RESERVE_STRICT_MODE` is inactive, container can still be received and the reserve is formalized later. If active, resolve the absent receipt order first before retrying PIE entry.
|
||||
|
||||
### Quantity discrepancy at PIE — container sent to reconditioning
|
||||
### Quantity discrepancy at PIE - container sent to reconditioning
|
||||
- **Cause:** ASN pre-notified quantity doesn't match the received quantity, and the receipt order does not allow excess.
|
||||
- **Solution:** Correct the discrepancy at the reconditioning station, then retry induction into the PIE.
|
||||
|
||||
@@ -79,7 +79,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
|
||||
### Transfer receipt order has no ASN
|
||||
- **Cause:** The source warehouse did not close the corresponding Transfer-type shipping order.
|
||||
- **Solution:** Verify the source warehouse has closed the transfer shipping order — ASN is auto-generated at that point.
|
||||
- **Solution:** Verify the source warehouse has closed the transfer shipping order - ASN is auto-generated at that point.
|
||||
|
||||
### Order stuck in "Receiving" status
|
||||
- **Cause:** Associated receipts are still open (not yet closed).
|
||||
@@ -97,11 +97,11 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
|
||||
## 2. Putaway
|
||||
|
||||
### No valid location found — manual warehouse
|
||||
### No valid location found - manual warehouse
|
||||
- **Cause:** All strategies exhausted; no location meets the combination of criteria + restrictions + rules. Common causes: all eligible zones full, location type mismatch, strategy sequence incomplete.
|
||||
- **Solution:** Operator must manually select a destination. Review: strategy sequence coverage, restrictions not overly restrictive, no locations marked full or locked.
|
||||
|
||||
### No valid location found — automatic warehouse (rejection task generated)
|
||||
### No valid location found - automatic warehouse (rejection task generated)
|
||||
- **Cause:** All aisles at the relocation percentage limit, no route from current station to any candidate, or weight limit exceeded everywhere.
|
||||
- **Solution:** Container is diverted to rejection station. Review aisle relocation configuration, available routes, and weight constraints.
|
||||
|
||||
@@ -144,7 +144,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
- **Solution:** Check lock type configuration. If the reason for the lock is resolved, unlock the LPN and re-process using alternative stock.
|
||||
|
||||
### Cannot modify LPN type or division type
|
||||
- **Cause:** LPN is not empty — still contains stock.
|
||||
- **Cause:** LPN is not empty - still contains stock.
|
||||
- **Solution:** Pick out or move all stock from the LPN, then change the type.
|
||||
|
||||
### ASN LPN cannot be deleted
|
||||
@@ -175,7 +175,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
- **Cause:** Stock is prepared for a shipping order inside a client container.
|
||||
- **Solution:** Un-prepare the stock via Shipping management, then adjust.
|
||||
|
||||
### Adjustment fails — reason required
|
||||
### Adjustment fails - reason required
|
||||
- **Cause:** No adjustment reason selected; none configured for the Adjustment capture process.
|
||||
- **Solution:** Create reasons in `Masters > Adjustment reasons`; select one before submitting the adjustment.
|
||||
|
||||
@@ -195,7 +195,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
|
||||
## 5. Picking / Order Preparation
|
||||
|
||||
### Order line stays incomplete — no stock assigned
|
||||
### Order line stays incomplete - no stock assigned
|
||||
- **Cause:** All stock assignment strategies exhausted without finding eligible stock. Typical causes: stock status blocks picking, count task active on the picking location, no PDL configured for item, extraction errors at candidate locations.
|
||||
- **Solution:** Check stock statuses, cancel any active count tasks on the location, verify PDL configuration, resolve extraction errors.
|
||||
|
||||
@@ -267,7 +267,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
- **Cause:** WMS-ERP integration issue, or order was closed without an active ERP connection.
|
||||
- **Solution:** Check integration configuration; retry via forced resend if the functionality is available.
|
||||
|
||||
### Cannot cancel order — stock already prepared
|
||||
### Cannot cancel order - stock already prepared
|
||||
- **Cause:** Picking tasks have been completed; stock is in a client container.
|
||||
- **Solution:** Undo preparation (un-prepare from the consolidation or truck loading view) before canceling.
|
||||
|
||||
@@ -312,14 +312,14 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
## 8. Count / Stock Adjustment
|
||||
|
||||
### Count order stuck in "Releasing"
|
||||
- **Cause:** Automatic warehouse — containers are still moving at release time.
|
||||
- **Cause:** Automatic warehouse - containers are still moving at release time.
|
||||
- **Solution:** Wait until all containers have reached a static location, then release the count order.
|
||||
|
||||
### Count line shows conflict icon — no stock
|
||||
### Count line shows conflict icon - no stock
|
||||
- **Cause:** Item count line requested for an item with zero stock in the warehouse.
|
||||
- **Solution:** Use "Force Close" to finalize the line; review item master to understand the discrepancy.
|
||||
|
||||
### Count line shows conflict icon — location not configured for count
|
||||
### Count line shows conflict icon - location not configured for count
|
||||
- **Cause:** Location does not have the "Allow count" flag enabled in EasyS.
|
||||
- **Solution:** Fix the location configuration in EasyS, or delete the problematic line.
|
||||
|
||||
@@ -332,7 +332,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
- **Expected behavior:** Task distribution adjusts dynamically. Fine-tune schedule parameters if distribution is too uneven.
|
||||
|
||||
### Cannot re-release a cycle count after cancel
|
||||
- **Cause:** By design — cycle count orders are non-re-releasable.
|
||||
- **Cause:** By design - cycle count orders are non-re-releasable.
|
||||
- **Solution:** Create a new manual count for the affected locations.
|
||||
|
||||
### No adjustment reasons visible on RFT
|
||||
@@ -384,14 +384,14 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
- **Solution:** Assign different equipment; check equipment-container type compatibility configuration.
|
||||
|
||||
### Task cannot be manually completed
|
||||
- **Cause:** Task type is picking, counting, stock replenishment, kit assembly, or consolidation — these must be completed through their respective process screens.
|
||||
- **Cause:** Task type is picking, counting, stock replenishment, kit assembly, or consolidation - these must be completed through their respective process screens.
|
||||
- **Solution:** Complete via the appropriate screen (picking station, count screen, etc.).
|
||||
|
||||
### Movement stuck "In Execution"
|
||||
- **Cause:** Automatic warehouse malfunction or communication failure.
|
||||
- **Solution:** Use "Movement Release" to reset the movement back to Pending; investigate the automation incident.
|
||||
|
||||
### Task canceled — container not found at location
|
||||
### Task canceled - container not found at location
|
||||
- **Cause:** Operator reported the wrong location at cancellation, or the container was moved without a system record.
|
||||
- **Solution:** Run a count on the expected location; use Lost & Found if needed.
|
||||
|
||||
@@ -403,7 +403,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
|
||||
## 11. AGV & Pallet Shuttle
|
||||
|
||||
### AGV notification events — full error code table
|
||||
### AGV notification events - full error code table
|
||||
|
||||
| Code | Error |
|
||||
|------|-------|
|
||||
@@ -419,10 +419,10 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
| 2003 | Extraction error at non-storage location |
|
||||
| 2004 | Putaway error at non-storage location |
|
||||
| 2005 | Manual cancellation from AGV interface |
|
||||
| 2500 | Communication error — sending order |
|
||||
| 2501 | Communication error — priority update |
|
||||
| 2502 | Communication error — cancellation |
|
||||
| 2503 | Communication error — destination change |
|
||||
| 2500 | Communication error - sending order |
|
||||
| 2501 | Communication error - priority update |
|
||||
| 2502 | Communication error - cancellation |
|
||||
| 2503 | Communication error - destination change |
|
||||
|
||||
### AGV extraction error
|
||||
- **Behavior:** No container found at pickup location.
|
||||
@@ -448,7 +448,7 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
### Pallet Shuttle low battery
|
||||
- **Behavior:** PS completes current tasks → returns to pickup position → disconnects → awaits AGV dispatch to charging station. If no charging station is available: user is notified.
|
||||
|
||||
### PS task in process — cannot be canceled
|
||||
### PS task in process - cannot be canceled
|
||||
- **Cause:** AGV system is already involved in the movement.
|
||||
- **Note:** Only tasks in "Pending" state (waiting/pending shipping with CREATE action) can be canceled. Tasks in any other state must complete.
|
||||
|
||||
@@ -556,11 +556,11 @@ Organized by **symptom category**. Each entry: symptom → cause → solution. F
|
||||
|
||||
## Related
|
||||
|
||||
- [Parameters](../concepts/parameters.md) — Full parameter reference; values controlling most behaviors above
|
||||
- [ERP Interface](../concepts/erp-interface.md) — All ERP message types, fields, and error codes
|
||||
- [Transactions](../concepts/transactions.md) — Transaction codes for audit trail investigation
|
||||
- [Security](../architecture/security.md) — Role and permission configuration
|
||||
- [System Architecture](../architecture/overview.md) — IIS pools, background jobs, infrastructure
|
||||
- [Quality Control](../concepts/quality-control.md) — Stock status lock/unlock system
|
||||
- [AGV](../modules/agv.md) — Full AGV error code reference
|
||||
- [Pallet Shuttle](../modules/pallet-shuttle.md) — PS diagnostics and error handling
|
||||
- [Parameters](../concepts/parameters.md) - Full parameter reference; values controlling most behaviors above
|
||||
- [ERP Interface](../concepts/erp-interface.md) - All ERP message types, fields, and error codes
|
||||
- [Transactions](../concepts/transactions.md) - Transaction codes for audit trail investigation
|
||||
- [Security](../architecture/security.md) - Role and permission configuration
|
||||
- [System Architecture](../architecture/overview.md) - IIS pools, background jobs, infrastructure
|
||||
- [Quality Control](../concepts/quality-control.md) - Stock status lock/unlock system
|
||||
- [AGV](../modules/agv.md) - Full AGV error code reference
|
||||
- [Pallet Shuttle](../modules/pallet-shuttle.md) - PS diagnostics and error handling
|
||||
|
||||
@@ -17,9 +17,9 @@ last_compiled: "2026-04-17"
|
||||
|
||||
Procédure interne Mecalux EasyWMS France pour **exporter la configuration / les données du WMS** (paramètres, profils, master data, etc.) depuis une VM via **uGNA Console**, et les commiter dans le Git du projet (dossier `..\test`).
|
||||
|
||||
À exécuter **systématiquement** avant tout commit dès qu'une nouvelle configuration, transporteur, paramètre ou autre master data a été ajouté(e) ou modifié(e) sur la VM. C'est l'une des trois étapes pré-commit (avec l'export custom app et la sauvegarde GNA si BOO modifiés) listées dans [git-workflow](git-workflow.md#étape-préalable--exporter-les-modifications).
|
||||
À exécuter **systématiquement** avant tout commit dès qu'une nouvelle configuration, transporteur, paramètre ou autre master data a été ajouté(e) ou modifié(e) sur la VM. C'est l'une des trois étapes pré-commit (avec l'export custom app et la sauvegarde GNA si BOO modifiés) listées dans [git-workflow](git-workflow.md#étape-préalable---exporter-les-modifications).
|
||||
|
||||
Source : Confluence EasyWMS France — *Export des données via uGNA* (v5, 18/10/2023).
|
||||
Source : Confluence EasyWMS France - *Export des données via uGNA* (v5, 18/10/2023).
|
||||
|
||||
## ⚠️ Prérequis : VM à jour
|
||||
|
||||
@@ -49,10 +49,10 @@ L'option `-Z:` accepte une liste séparée par virgules. La commande standard ci
|
||||
|
||||
| Domaine | Entités |
|
||||
|---|---|
|
||||
| Master data — Owners / Accounts | `owner`, `account`, `accounttype`, `company` |
|
||||
| Master data — Items | `product`, `productfamily`, `productype`, `productlocation`, `alias`, `uom` |
|
||||
| Master data — Suppliers / Carriers | `supplier`, `suppliertype`, `agency`, `deliveriescarrier`, `carrierselectionconfiguration` |
|
||||
| Master data — Kits & Hazards | `kit`, `hazzardclass`, `divtype` |
|
||||
| Master data - Owners / Accounts | `owner`, `account`, `accounttype`, `company` |
|
||||
| Master data - Items | `product`, `productfamily`, `productype`, `productlocation`, `alias`, `uom` |
|
||||
| Master data - Suppliers / Carriers | `supplier`, `suppliertype`, `agency`, `deliveriescarrier`, `carrierselectionconfiguration` |
|
||||
| Master data - Kits & Hazards | `kit`, `hazzardclass`, `divtype` |
|
||||
| Profils | `logisticprofile`, `receptionprofile`, `putawayprofile`, `shippingprofile`, `cuttingprofile`, `countprofiles` |
|
||||
| Stratégies | `putawaystrategy`, `putawayrestriction`, `replenishmentstrategy`, `stockassignstrategy`, `stockassignstrategyV2`, `ShippingProfileAssignmentStrategy`, `stockclassificationbyzone` |
|
||||
| Classes & ABC | `inboundclass`, `outboundclass`, `abc` |
|
||||
@@ -83,7 +83,7 @@ Si l'export échoue avec une erreur d'écriture sur `C:\Program Files (x86)\Meca
|
||||
|
||||
## Related
|
||||
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) — étape pré-commit "export uGNA"
|
||||
- [GNA, Services & License](gna-services-license.md) — sauvegarde des fichiers BOO du GNA (`GNAGetDataForGit.ps1`), processus distinct de l'export uGNA
|
||||
- [First Deployment](first-deployment.md) — l'arborescence `..\test` est consommée à la première installation (`Data: test/`)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — les exports uGNA sont rechargés à chaque redéploiement
|
||||
- [Git Workflow (Git Flow)](git-workflow.md) - étape pré-commit "export uGNA"
|
||||
- [GNA, Services & License](gna-services-license.md) - sauvegarde des fichiers BOO du GNA (`GNAGetDataForGit.ps1`), processus distinct de l'export uGNA
|
||||
- [First Deployment](first-deployment.md) - l'arborescence `..\test` est consommée à la première installation (`Data: test/`)
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - les exports uGNA sont rechargés à chaque redéploiement
|
||||
|
||||
@@ -25,7 +25,7 @@ La VM sert de cible de déploiement pour :
|
||||
- La **custom application** du projet (via EasyBuilder)
|
||||
- Les services adjacents (GNA, Printer Service, EasySTS License, SmartUI, etc.)
|
||||
|
||||
Sources : Confluence EasyWMS France — *Installation de la VM sur Hyper-V* (v30, 02/12/2025) + *Valider sa machine virtuelle* (v7, 14/02/2023).
|
||||
Sources : Confluence EasyWMS France - *Installation de la VM sur Hyper-V* (v30, 02/12/2025) + *Valider sa machine virtuelle* (v7, 14/02/2023).
|
||||
|
||||
## Prérequis
|
||||
|
||||
@@ -78,7 +78,7 @@ La convention `DEV-<PRENOM>` évite les interconnexions non désirées entre VM
|
||||
- IP : `10.255.255.2`
|
||||
- Masque : `255.255.255.0`
|
||||
- Passerelle : `10.255.255.1`
|
||||
4. **Advanced → DNS** — saisir les 4 serveurs DNS Mecalux :
|
||||
4. **Advanced → DNS** - saisir les 4 serveurs DNS Mecalux :
|
||||
- `192.168.0.102`
|
||||
- `192.168.0.104`
|
||||
- `192.168.0.56`
|
||||
@@ -88,7 +88,7 @@ La convention `DEV-<PRENOM>` évite les interconnexions non désirées entre VM
|
||||
## 5. Renommer la VM (Windows)
|
||||
|
||||
1. **Paramètres Windows → System → About** (en bas du volet gauche)
|
||||
2. **"Rename this PC"** — saisir le nom de la VM
|
||||
2. **"Rename this PC"** - saisir le nom de la VM
|
||||
|
||||
> ⚠️ **Avant redémarrage**, mettre à jour les fichiers Oracle suivants (remplacer `localhost` par le nouveau nom) :
|
||||
> - `tnsnames.ora`
|
||||
@@ -106,13 +106,13 @@ La convention `DEV-<PRENOM>` évite les interconnexions non désirées entre VM
|
||||
|
||||
Avant le premier point de contrôle, installer ce qui est nécessaire :
|
||||
|
||||
- **Git** (obligatoire) — vérifier avec `git --version` ; à défaut : [git-scm.com/download/win](https://git-scm.com/download/win)
|
||||
- **Git** (obligatoire) - vérifier avec `git --version` ; à défaut : [git-scm.com/download/win](https://git-scm.com/download/win)
|
||||
- Éditeurs personnels (Sublime Text, VSCode, Notepad++…)
|
||||
- SourceTree si absent du template (voir [git-workflow](git-workflow.md))
|
||||
|
||||
## 7. Point de contrôle "Deploy 0"
|
||||
|
||||
Créer un point de contrôle **"Deploy 0"** — c'est le snapshot de référence à partir duquel un nouveau projet pourra être déployé (cf. [first-deployment](first-deployment.md)).
|
||||
Créer un point de contrôle **"Deploy 0"** - c'est le snapshot de référence à partir duquel un nouveau projet pourra être déployé (cf. [first-deployment](first-deployment.md)).
|
||||
|
||||
Entre deux projets, on applique ce point de contrôle pour repartir d'une VM propre.
|
||||
|
||||
@@ -123,7 +123,7 @@ Après le premier déploiement d'un projet sur la VM (cf. [first-deployment](fir
|
||||
### 1. Vérifier les services et IIS
|
||||
|
||||
1. Service Windows **MongoDB** démarré (sinon : démarrer)
|
||||
2. **IIS Manager** — pour chacune des applications ci-dessous, `Browse` doit ouvrir la page sans erreur :
|
||||
2. **IIS Manager** - pour chacune des applications ci-dessous, `Browse` doit ouvrir la page sans erreur :
|
||||
- **`AD`** (Application Dictionary API)
|
||||
- **`ApplicationService`**
|
||||
- **`EasySTS`** (License)
|
||||
@@ -163,8 +163,8 @@ Si la connexion à **consoleRF** boucle sur l'input du nom d'utilisateur :
|
||||
|
||||
## Related
|
||||
|
||||
- [System Architecture Overview](../architecture/overview.md) — stack IIS/ASP.NET Core/Oracle/PostgreSQL déployée sur la VM
|
||||
- [First Deployment](first-deployment.md) — déploiement initial d'un projet sur une VM fraîchement créée
|
||||
- [Deploy Existing Application](deployment-existing-app.md) — redéploiement sur VM déjà préparée
|
||||
- [GNA, Services & License](gna-services-license.md) — installation des services adjacents (GNA, Printer, License WMS)
|
||||
- [Development Methodology](development-methodology.md) — méthode de travail et stratégie de branches autour de la VM
|
||||
- [System Architecture Overview](../architecture/overview.md) - stack IIS/ASP.NET Core/Oracle/PostgreSQL déployée sur la VM
|
||||
- [First Deployment](first-deployment.md) - déploiement initial d'un projet sur une VM fraîchement créée
|
||||
- [Deploy Existing Application](deployment-existing-app.md) - redéploiement sur VM déjà préparée
|
||||
- [GNA, Services & License](gna-services-license.md) - installation des services adjacents (GNA, Printer, License WMS)
|
||||
- [Development Methodology](development-methodology.md) - méthode de travail et stratégie de branches autour de la VM
|
||||
|
||||
@@ -20,7 +20,7 @@ Cette page décrit :
|
||||
- Les modes d'accès (localhost depuis la VM, IP depuis un autre poste)
|
||||
- Les passerelles VPN à utiliser depuis une délégation Europe
|
||||
|
||||
Source : Confluence EasyWMS France — *Routage vers les VM* (v7, 11/08/2023).
|
||||
Source : Confluence EasyWMS France - *Routage vers les VM* (v7, 11/08/2023).
|
||||
|
||||
## 1. Tableau de correspondance NAT
|
||||
|
||||
@@ -32,7 +32,7 @@ Source : Confluence EasyWMS France — *Routage vers les VM* (v7, 11/08/2023).
|
||||
| Oracle | 1521 | **15210** | 15211 |
|
||||
| SMB | 445 | **4450** | 4451 |
|
||||
|
||||
> Toute requête TCP reçue sur le PC hôte sur le port **8080** est redirigée vers **10.255.255.2:80** (l'IP fixe de la VM, cf. [vm-installation](vm-installation.md#configuration-réseau-ipv4)). Le port externe n°2 sert quand on doit faire tourner **deux VMs en parallèle** sur le même hôte.
|
||||
> Toute requête TCP reçue sur le PC hôte sur le port **8080** est redirigée vers **10.255.255.2:80** (l'IP fixe de la VM, cf. [vm-installation](vm-installation.md#4-configuration-réseau-dans-la-vm-locale)). Le port externe n°2 sert quand on doit faire tourner **deux VMs en parallèle** sur le même hôte.
|
||||
|
||||
### Commandes Windows utiles
|
||||
|
||||
@@ -50,21 +50,21 @@ Depuis l'intérieur de la VM, on utilise **`localhost`** + port interne, ou dire
|
||||
| EasyBuilder en HTTPS | `localhost:4430` |
|
||||
| SmartUI via DNS | `https://<nom_vm>/smartui/` |
|
||||
|
||||
> Note : `4430` est le port externe NAT — depuis la VM, accéder via `localhost:443` fonctionne aussi pour HTTPS interne. La doc Confluence donne `localhost:4430` car la VM peut être interrogée via la machine hôte qui résout le NAT.
|
||||
> Note : `4430` est le port externe NAT - depuis la VM, accéder via `localhost:443` fonctionne aussi pour HTTPS interne. La doc Confluence donne `localhost:4430` car la VM peut être interrogée via la machine hôte qui résout le NAT.
|
||||
|
||||
## 3. Accès **depuis un autre PC**
|
||||
|
||||
`localhost` et le **DNS de la VM** ne sont **pas accessibles** depuis un autre poste — il faut utiliser l'**IP du PC hôte** suivie du port externe NAT.
|
||||
`localhost` et le **DNS de la VM** ne sont **pas accessibles** depuis un autre poste - il faut utiliser l'**IP du PC hôte** suivie du port externe NAT.
|
||||
|
||||
### Récupérer son IP
|
||||
|
||||
**Option A — Paramètres Windows :**
|
||||
**Option A - Paramètres Windows :**
|
||||
1. Clic droit sur l'icône réseau dans la barre des tâches
|
||||
2. **"Ouvrir les paramètres réseau et Internet"**
|
||||
3. **"Propriétés"** de l'adaptateur Ethernet
|
||||
4. Récupérer l'**adresse IPv4**
|
||||
|
||||
**Option B — PowerShell :**
|
||||
**Option B - PowerShell :**
|
||||
```powershell
|
||||
ipconfig
|
||||
```
|
||||
@@ -79,7 +79,7 @@ Récupérer l'**IPv4** de l'adaptateur Ethernet.
|
||||
| SmartUI | `192.168.164.214:4430/smartui` |
|
||||
| Bureau à distance (RDP) | `192.168.164.214:33890` |
|
||||
|
||||
> Pour que SmartUI s'affiche correctement depuis le PC hôte, il faut aussi avoir vidé `defaultURL` dans `SmartUI\script\config.js` (cf. [vm-installation — Validation](vm-installation.md#validation-de-la-vm)).
|
||||
> Pour que SmartUI s'affiche correctement depuis le PC hôte, il faut aussi avoir vidé `defaultURL` dans `SmartUI\script\config.js` (cf. [vm-installation - Validation](vm-installation.md#validation-de-la-vm)).
|
||||
|
||||
## 4. Utilisation avec le VPN Mecalux
|
||||
|
||||
@@ -113,5 +113,5 @@ No Hyper-V NAT connectivity
|
||||
|
||||
## Related
|
||||
|
||||
- [VM Installation (Hyper-V) & Validation](vm-installation.md) — création de la VM, IP fixe `10.255.255.2`, commutateur InternoNAT
|
||||
- [Deploy Test Application](deploy-test-application.md) — déploiement d'une livraison sur la VM de test (utilise ces accès réseau)
|
||||
- [VM Installation (Hyper-V) & Validation](vm-installation.md) - création de la VM, IP fixe `10.255.255.2`, commutateur InternoNAT
|
||||
- [Deploy Test Application](deploy-test-application.md) - déploiement d'une livraison sur la VM de test (utilise ces accès réseau)
|
||||
|
||||
Reference in New Issue
Block a user