Bekannte Probleme

Die nachfolgend aufgeführten bekannten Probleme sind aus dem Bereich Customizing. Weitere bekannte Probleme finden Sie in den folgenden Dokumentationsbereichen:

Bekannte Probleme

Problem
Neu angelegte OLEs werden nicht sofort im Modul OLEs angezeigt, sondern erst nach Neustart des Systems.
Die Wertebereich-Funktion EXPAND() wird nur einmal berechnet.
In Gruppierungsbereichen, deren DDI ein Inkarnations-DI ist, kann es zu Problemen beim Einfügen neuer Gruppen kommen. Daher sollte stattdessen das Unter-DI des Inkarnations-DI mit der Funktion = KO verwendet werden.
Der Oracle-Fehler im Logfile OCIError: ORA-24432: Die zurückgegebene Anweisung ist keine Tagged-Anweisung. ist keine wirkliche Fehlermeldung, sondern eine Warnung und kann ignoriert werden.
In Modulen mit aktiviertem Parameter Neben Oberbereich und bestehenden Relationen zwischen den Datenbereichen kann es zu Darstellungsproblemen kommen.
Post-Delete-Events funktionieren derzeit in Python nicht, da der zu übergebende DtpRecord zu dem Zeitpunkt bereits nicht mehr existiert.

Bekannte Probleme mit Lösung

Problem mit `mod_obj.menu(91)` / Aktions-ID 91

Das System hängt sich auf, wenn Menüpunkt 91 in ein Modul eingebunden wird. Dies kann durch ein Python-Makro oder eine Aktions-ID im Datenbereich passieren.

Auf einem Datenfeld mit DF-Verhalten = c2 sollte als Aktions-ID keine 91 mehr vergeben werden, um Fehler zu vermeiden.
In allen Makros, in denen mod_obj.menu(91) verwendet wird, um einen untergeordneten Datenbereich einzufügen, muss man nun explizit angeben, in welchem Datenbereich ein Datensatz eingefügt werden soll. Dies geschieht über die DA-Python-ID.
Lösung:

PY

Old: 
mod_obj=ppms.get_target_module()
mod_obj.menu(91)

New:
inv_rec=ppms.get_context_df().get_record()
inv_rec.insert_child(str(DA-Python-ID))

Der Vorteil dieser Vorgehensweise ist, dass genau darüber entschieden werden kann, in welchem Datenbereich ein Datensatz eingefügt wird.

Datenbank-Fehlermeldung beim Speichern in der Q1B und Q2B nach einem CU-Deployment

Beim Speichern von Änderungen in den Customizing-Schemas Q1B und Q2B (z.B. im Modul Module oder Datenbereiche) tritt nach einem CU-Deployment eine Datenbank-Fehlermeldung auf.

Lösung:
- Die HIBERNATE_SEQUENCE muss manuell auf den höchsten Stand der in den History-Tabellen vorhanden Daten gesetzt werden.

Überschreiben von komplexeren Python-Customizings

Informationen

Standardmäßig wird empfohlen, die Import-Wrapper zu nutzen, um Standard-Funktionalitäten abzuändern.
Bei bestimmten Programmierungen ist dies aber nicht möglich. In diesen Fällen muss wie folgt vorgegangen werden:
- Der Code in der Datei, die unter /planta_de/ liegt muss angepasst werden.
- Die Veränderung muss im ICOU dokumentiert werden.
- Bei jedem Update muss die Änderung wieder zurückgespielt werden.

Details

Beispiel für eine solche Programmierung:
- Die Funktion apply_project_parameter_heredity wird von create_project_by_type in create_project.py aufgerufen.
- Diese Funktion ruft wiederrum insert_project_child_records auf, um die Stakeholder bei einem Teilprojekt vom Hauptprojekt zu kopieren.
- Wird die Funktion insert_project_child_records durch die Import-Wrapper überschrieben, hat das keine Auswirkung auf dieses Verhalten.

Begründung:
- Beide Funktionen befinden sich im gleichen Modul, was ihren lokalen Namespace darstellt.
- Will nun die Funktion _apply_project_parameter_heredity die Funktion insert_project_child_records aufrufen, wird nach dieser Funktion erst im lokalen Namespace gesucht, bevor die Suche ausgeweitet wird.
- Ist die Funktion also im customer-Verzeichnis überschrieben, kommt der Code nie soweit, dass er dort nachschauen müsste, weil die Funktion bereits im lokalen Namespace gefunden wird.

Behobene Probleme

Problem mit Validierung neuer individueller Mapping-Funktionen (behoben ab DB 39.5.25)

Neue individuelle Mapping-Funktionen werden von der Schnittstellenvalidierung nicht erkannt.

Ursache: Das Customizing wurde geändert, um das Attribut category für den Klassennamen zu verwenden, aber es gab immer noch eine Stelle, in der nach dem Attribut name gesucht wurde.
Lösung: Bitte die folgenden Einträge in der src/Python/py/api/ppms/customizing/venus/ppms/interface/blocks/base.py ersetzen:

CODE

        for listbox_record in category_record.get_children(447, ['name', 'description']):
            name = listbox_record.name.get_value()

durch

CODE

        for listbox_record in category_record.get_children(447, ['category', 'description']):
            name = listbox_record.category.get_value()

UUIDs in PLANTA link-Datentabellen (behoben ab DB 39.5.24)

PLANTA link erfordert fälschlicherweise zwingend eine UUID für Datentabellen, die in den Schnittstellen verwendet werden, und erwartet, dass die UUID "uuid" als Python-ID besitzt.

Lösung: Bitte die folgenden Einträge in der Datei py/api/ppms/customizing/venus/ppms/interface/modules/mts.py ersetzen:

CODE

            uuid_di = dtp_record.get_di('uuid')

durch

CODE

        try:
            uuid_di = dtp_record.get_di('uuid')
        except ppms.NonexistentDataItem:
            return

Problem mit Validierung neuer individueller Mapping-Funktionen (behoben ab DB 39.5.24)

Neue individuelle Mapping-Funktionen werden von der Schnittstellenvalidierung nicht erkannt.

Ursache: Das Customizing wurde geändert, um das Attribut category für den Klassennamen zu verwenden, aber es gab immer noch eine Stelle, in der nach dem Attribut name gesucht wurde.
Lösung: Bitte die folgenden Einträge in der src/Python/py/api/ppms/customizing/venus/ppms/interface/blocks/base.py ersetzen:

CODE

        for listbox_record in category_record.get_children(447, ['name', 'description']):
            name = listbox_record.name.get_value()

durch

CODE

        for listbox_record in category_record.get_children(447, ['category', 'description']):
            name = listbox_record.category.get_value()