Getrennte Systeme, gemeinsame Logik: Wie ich Geschäftsprozesse mit Access steuere und WordPress als Frontend nutze

Warum getrennte Systeme?

Ich trenne konsequent zwischen Logik und Darstellung.
Access regelt die Fachprozesse.
WordPress zeigt nur, was gezeigt werden darf – und fragt Access, wenn es etwas wissen will.

Das ist nicht altmodisch.
Das ist robust, nachvollziehbar und wartbar.
Gerade im KMU-Umfeld, wo Ressourcen knapp und Anforderungen speziell sind.

Prinzip: Access denkt, WordPress zeigt

Schicht	Aufgabe
Access	Geschäftsregeln, Prüfungen, Prozesse
WordPress	Web-Frontend, Formulare, Anzeige
Middleware (optional)	REST-Proxy, Authentifizierung

Das klingt nach Overhead – ist aber am Ende effizienter.
Denn Access kennt die Regeln seit Jahren.
Und WordPress muss nicht mehr nachdenken – nur darstellen.

Beispiel 1: Lieferfreigabe mit Prüfregeln

Der Prozess

1. Kunde gibt über ein Formular auf der Website eine Wunschlieferung ein
2. WordPress sendet die Daten via REST an Access
3. Access prüft die Regeln (z. B. Sperrzeiten, Stückzahlbegrenzung, Wochenend-Stopps)
4. Ergebnis: „Genehmigt“ oder „Zurückgewiesen“
5. WordPress zeigt Feedback im Kundenbereich

Access-Funktion

Public Function PrüfeLieferung(Kunde As Long, Artikel As Long, Menge As Long, Termin As Date) As String
    If Weekday(Termin, vbMonday) > 5 Then
        PrüfeLieferung = "Wochenende nicht erlaubt"
        Exit Function
    End If

    If Menge > 100 Then
        PrüfeLieferung = "Maximal 100 Stück erlaubt"
        Exit Function
    End If

    PrüfeLieferung = "OK"
End Function

API-Endpunkt (PHP)

add_action('rest_api_init', function () {
  register_rest_route('intern/v1', '/pruefe-lieferung', [
    'methods' => 'POST',
    'callback' => 'liefere_zulassung',
    'permission_callback' => '__return_true'
  ]);
});

function liefere_zulassung($request) {
  $data = $request->get_json_params();
  $antwort = file_get_contents("http://access-server:8081/check?kunde={$data['kunde']}&artikel={$data['artikel']}&menge={$data['menge']}&datum={$data['termin']}");
  return ['ergebnis' => trim($antwort)];
}

WordPress zeigt dann nur das Ergebnis.
Die Logik bleibt in Access – da, wo sie auch gepflegt wird.

Beispiel 2: Statuswechsel aus dem WordPress-Backend

Mitarbeiter sollen online den Status einer Lieferung ändern können.
Aber der Statuswechsel soll geprüft werden – z. B. ob bereits Teillieferungen bestehen.

WordPress schickt:

fetch('/wp-json/intern/v1/set-status', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ id: 123, neuer_status: 'Abgeschlossen' })
});

Access prüft:

Public Function SetzeStatus(LieferungID As Long, NeuerStatus As String) As String
    If DCount("*", "tbl_Teillieferung", "LieferungID=" & LieferungID) > 0 Then
        If NeuerStatus = "Storniert" Then
            SetzeStatus = "Nicht erlaubt: Teillieferung existiert"
            Exit Function
        End If
    End If
    
    CurrentDb.Execute "UPDATE tbl_Lieferung SET Status='" & NeuerStatus & "' WHERE ID=" & LieferungID
    SetzeStatus = "OK"
End Function

Tabellenstruktur: Neutral und kompatibel

Ich halte meine Datenbank neutral – ohne WordPress-Felder wie post_id, ohne Access-spezifische Datentypen.

Beispiel:

Feld	Typ	Zweck
ID	Long	Primärschlüssel
KundeID	Long	Fremdschlüssel tbl_Kunde
ArtikelID	Long	Fremdschlüssel tbl_Artikel
Status	Text(50)	„Offen“, „Geplant“, „Erledigt“
SichtbarWeb	Ja/Nein	Steuerung Web-Ausgabe

WordPress ruft nur Datensätze mit SichtbarWeb=True ab – über einen API-Proxy oder View.

Reporting: Access → WordPress PDF oder JSON

Access erstellt Berichte (z. B. Lieferscheine, Sammelübersichten) als PDF.

DoCmd.OutputTo acOutputReport, "rpt_Lieferung", acFormatPDF, "C:\tmp\lieferung_123.pdf"

Dann via REST-Upload an WordPress:

wp_upload_bits("lieferung_123.pdf", null, file_get_contents("C:/tmp/lieferung_123.pdf"));

Alternativ gibt Access JSON zurück, WordPress rendert es im Frontend.

Sicherheit

• WordPress kennt keine Access-Verbindungsdaten
• Access antwortet nur auf autorisierte Anfragen
• Businesslogik liegt nicht offen im Web
• Statusänderungen, Prüfungen und Regeln bleiben zentral

Mein Fazit

Getrennte Systeme machen Sinn – wenn die Zuständigkeiten klar sind.
Access denkt. WordPress zeigt.
Und der Code bleibt dort, wo er gepflegt werden kann.

Der Schäfer steht im Stall.
Der Schafzaun ist WordPress.
Und beide tun genau das, was sie sollen.