1. Kartendarstellung (Neutralisierung):
* Die TileLayer-URL in heatmap-tool/frontend/src/components/MapDisplay.tsx wurde auf eine neutrale CARTO light_all-Kachelansicht umgestellt und die Quellenangabe entsprechend angepasst.
Wir haben versucht, auf eine neu erstellte Zusatz-Tabelle (ExtraTableId 1, auch y_marketing_copy oder Marketing Ansprache genannt) in SuperOffice zuzugreifen, um dort Marketing-Texte zu speichern. Dabei sind wir auf eine
hartnäckige Blockade gestoßen:
Einrichtung der Entwicklungsumgebung auf der neuen VM docker1 (Ubuntu 24.04). Fehlerbehebung bei Docker-DNS-Problemen (systemd-resolved). Installation und Konfiguration einer frischen Gitea-Instanz via Docker Compose (manuelle Web-Installation für Konsistenz). Bereitstellung der Gemini CLI-Umgebung (Docker-basiert mit startgemini.sh Workflow). Dokumentation der Schritte in umzug.md erstellt.
1. Professionalisierung & Code-Härtung ("Enterprise Ready")
* Zentrales Logging: Wir haben eine logging_config.py implementiert. Der Connector schreibt jetzt professionelle, rotierende Log-Dateien (mit Zeitstempel und Modulnamen), statt nur
print-Ausgaben in die Konsole zu werfen. Das ist essenziell für den stabilen Betrieb auf der VM.
* Decoupling (Entkopplung): Alle festkodierten Werte (wie die mühsam ermittelten MA-Status-IDs 11–18 oder die UDF-ProgIds) wurden aus dem Logik-Code entfernt und in eine zentrale
config.py ausgelagert. Diese kann nun einfach über Umgebungsvariablen für die Produktion (Prod) angepasst werden.
* Refactoring: Sämtliche Module (SuperOfficeClient, AuthHandler, ExplorerClient) wurden bereinigt, redundante Kommentare entfernt und auf die neue Konfigurationsstruktur umgestellt.
- Integrated centralized logging system in all modules.
- Extracted all IDs and ProgIds into a separate .
- Refactored and for cleaner dependency management.
- Included updated discovery and inspection utilities.
- Verified end-to-end workflow stability.
1. Umfassende Entitäten-Erstellung: Wir haben erfolgreich Methoden implementiert, um die Kern-SuperOffice-Entitäten per API zu erstellen:
* Firmen (`Contact`)
* Personen (`Person`)
* Verkäufe (`Sale`) (entspricht D365 Opportunity)
* Projekte (`Project`) (entspricht D365 Campaign), inklusive der Verknüpfung von Personen als Projektmitglieder.
2. Robuste UDF-Aktualisierung: Wir haben eine generische und fehlertolerante Methode (update_entity_udfs) implementiert, die benutzerdefinierte Felder (UDFs) für sowohl Contact- als
auch Person-Entitäten aktualisieren kann. Diese Methode ruft zuerst das bestehende Objekt ab, um die Konsistenz zu gewährleisten.
3. UDF-ID-Discovery: Durch eine iterative Inspektionsmethode haben wir erfolgreich alle internen SuperOffice-IDs für die Listenwerte deines MA Status-Feldes (Ready_to_Send, Sent_Week1,
Sent_Week2, Bounced, Soft_Denied, Interested, Out_of_Office, Unsubscribed) ermittelt und im Connector hinterlegt.
4. Vollständiger End-to-End Test-Workflow: Unser main.py-Skript demonstriert nun einen kompletten Ablauf, der alle diese Schritte von der Erstellung bis zur UDF-Aktualisierung umfasst.
5. Architekturplan für Marketing Automation: Wir haben einen detaillierten "Butler-Service"-Architekturplan für die Marketing-Automatisierung entworfen, der den Connector für die
Textgenerierung und SuperOffice für den Versand und das Status-Management nutzt.
6. Identifikation des E-Mail-Blockers: Wir haben festgestellt, dass das Erstellen von E-Mail-Aktivitäten per API in deiner aktuellen SuperOffice-Entwicklungsumgebung aufgrund fehlender
Lizenzierung/Konfiguration des E-Mail-Moduls blockiert ist (500 Internal Server Error).
7. Feiertagslogik ergänzt
- **Company Explorer Sync**: Added `explorer_client.py` and integrated Step 9 in `main.py` for automated data transfer to the intelligence engine.
- **Holiday Logic**: Implemented `BusinessCalendar` in `utils.py` using the `holidays` library to automatically detect weekends and Bavarian holidays, ensuring professional timing for automated outreaches.
- **API Discovery**: Created `parse_ce_openapi.py` to facilitate technical field mapping through live OpenAPI analysis.
- **Project Stability**: Refined error handling and logging for a smooth end-to-end workflow.
1. Umfassende Entitäten-Erstellung: Wir haben erfolgreich Methoden implementiert, um die Kern-SuperOffice-Entitäten per API zu erstellen:
* Firmen (`Contact`)
* Personen (`Person`)
* Verkäufe (`Sale`) (entspricht D365 Opportunity)
* Projekte (`Project`) (entspricht D365 Campaign), inklusive der Verknüpfung von Personen als Projektmitglieder.
2. Robuste UDF-Aktualisierung: Wir haben eine generische und fehlertolerante Methode (update_entity_udfs) implementiert, die benutzerdefinierte Felder (UDFs) für sowohl Contact- als
auch Person-Entitäten aktualisieren kann. Diese Methode ruft zuerst das bestehende Objekt ab, um die Konsistenz zu gewährleisten.
3. UDF-ID-Discovery: Durch eine iterative Inspektionsmethode haben wir erfolgreich alle internen SuperOffice-IDs für die Listenwerte deines MA Status-Feldes (Ready_to_Send, Sent_Week1,
Sent_Week2, Bounced, Soft_Denied, Interested, Out_of_Office, Unsubscribed) ermittelt und im Connector hinterlegt.
4. Vollständiger End-to-End Test-Workflow: Unser main.py-Skript demonstriert nun einen kompletten Ablauf, der alle diese Schritte von der Erstellung bis zur UDF-Aktualisierung umfasst.
5. Architekturplan für Marketing Automation: Wir haben einen detaillierten "Butler-Service"-Architekturplan für die Marketing-Automatisierung entworfen, der den Connector für die
Textgenerierung und SuperOffice für den Versand und das Status-Management nutzt.
6. Identifikation des E-Mail-Blockers: Wir haben festgestellt, dass das Erstellen von E-Mail-Aktivitäten per API in deiner aktuellen SuperOffice-Entwicklungsumgebung aufgrund fehlender
Lizenzierung/Konfiguration des E-Mail-Moduls blockiert ist (500 Internal Server Error).
1. Strategische Klärung & Dokumentation: Wir haben die Rolle der SuperOffice-Entitäten Sale (als D365 Opportunity) und Project (als D365 Campaign) in unserem Integrationsplan geklärt
und dies in der SUPEROFFICE_INTEGRATION_PLAN.md dokumentiert.
2. `Sale` (Verkauf/Opportunity) Implementierung:
* Ich habe die Methode create_sale in superoffice_client.py implementiert, um Verkaufschancen anzulegen.
* Wir haben diese Funktion erfolgreich getestet und dabei gelernt, dass das Titelfeld in SuperOffice Heading statt Title heißt. Die Implementierung und das Logging wurden
entsprechend korrigiert.
3. `Project` (Projekt/Kampagne) Implementierung:
* Ich habe die Methode create_project in superoffice_client.py implementiert, um Marketing-Projekte zu erstellen.
* Nach anfänglichen API-Herausforderungen (falsche HTTP-Methode und Endpunkt für Projektmitglieder) habe ich die create_project-Methode so angepasst, dass Projektmitglieder direkt
beim Erstellen des Projekts übergeben werden.
* Diese Funktionalität wurde ebenfalls erfolgreich getestet.
4. End-to-End-Workflow Demonstration: Das main.py-Skript demonstriert nun erfolgreich den gesamten Workflow: Anlegen einer Firma (Contact), einer Person (Person), eines Verkaufs (Sale)
und eines Projekts (Project), wobei die Person direkt dem Projekt zugeordnet wird.
5. Detaillierter Plan für Marketing Automation: Wir haben einen sehr detaillierten Plan für die Marketing-Automatisierung über SuperOffice erarbeitet. Dieser "Butler-Service"-Ansatz
sieht vor, dass der Connector E-Mail-Inhalte generiert und in SuperOffice-Feldern speichert, während der Versand manuell durch den User im SuperOffice-Client erfolgt.
6. Dokumentation des Marketing-Automationsplans: Dieser detaillierte Plan, einschließlich der benötigten benutzerdefinierten Felder (UDFs) und des Workflows, wurde 1:1 in der
connector-superoffice/README.md dokumentiert.
This commit extends the SuperOffice connector to support the creation and linking of Sale \(Opportunity\) and Project \(Campaign\) entities, providing a comprehensive foundation for both sales and marketing automation workflows.
Key achievements:
- **`SUPEROFFICE_INTEGRATION_PLAN.md`**: Updated to include strategic mapping of D365 concepts \(Opportunity, Campaign\) to SuperOffice entities \(Sale, Project\).
- **`connector-superoffice/superoffice_client.py`**:
- Implemented `create_sale` method to generate new opportunities, correctly mapping `Title` to SuperOffices
1. Analyse der Änderungen:
* superoffice_client.py: Implementierung der Methoden create_contact (Standardfelder) und create_person (inkl. Firmenverknüpfung).
* auth_handler.py: Härtung der Authentifizierung durch Priorisierung von SO_CLIENT_ID und Unterstützung für load_dotenv(override=True).
* main.py: Erweiterung des Test-Workflows für den vollständigen Lese- und Schreib-Durchstich (Erstellung von Demo-Firmen und Personen).
* README.md: Aktualisierung des Status Quo und der verfügbaren Client-Methoden.
Completed POC for SuperOffice integration with the following key achievements:
- Switched from RSA/SOAP to OAuth 2.0 (Refresh Token Flow) for better compatibility with SOD environment.
- Implemented robust token refreshing and caching mechanism in .
- Solved 'Wrong Subdomain' issue by enforcing for tenant .
- Created for REST API interaction (Search, Create, Update UDFs).
- Added helper scripts: , , .
- Documented usage and configuration in .
- Updated configuration requirements.
[2ff88f42]
Establishes the initial structure for the SuperOffice connector. Implements the complete, iterative authentication process, culminating in a successful refresh token exchange. Documents the process and the final blocker (API authorization) in the integration plan, awaiting IT action to change the application type to 'Server to server'.
