====== System Revision ======

This Howto tries to show a proven, manual procedure for system analysis/revision. Practice shows that EDI landscapes are subject to frequent changes or adaptations to given situations.
Therefore, the extensions tend to make a system confusing and often even contain obsolete artifacts, which then make the overview even more difficult.
eBiss offers suitable methods to keep where-used lists for the most important objects and to follow the processes from A-Z via hyperlink through the different process instances.
Nevertheless, certain things remain somewhat hidden and only become apparent through further analysis.

{{:images:sign_warning.png?nolink|}}**Note:** With the module [[en:ueberblick:ebiss_module:analytics:start|]] many of the following steps can already be prepared automatically and inserted into your own system documentation under [[en:mysystem:start]].

The system revision is a **Reverse engineering** which reverses and/or opens up the process described under [[en:howtos:data_rail]].

{{:images:sign_warning.png?nolink|}}**Note:** A consistent application of the [[en:howtos:namingconventions]] facilitates the system analysis and increases the consistency crucially.

With the following steps it is possible to analyze a system for its actual function.

===== 1. Identify Automation =====

Identify the active [[en:prozessdefinition:automatisierungen:automatisierungen|]]s((Note: only active automations trigger automatic processes!))

===== 2. Identify processes =====

==== Prozess classification ====

Open the job(({{:images:sign_warning.png?nolink|}}**Note:** See also [[en:ueberblick:start#typical_process|Typical process]])) via the link in the active automation and identify its task.((The main distinction is made based on the job objects located in the job.)).
    - INBOUND process can be recognized by the direction setting "INBOUND" of the [[en:kommunikation:kanal:start|ReceiveChannel]] or [[en:prozessdefinition:jobs:jobsteps:kommunikation:backend:backendobjectretrieverex|BackendObjectRetriever]] used in it((Receive channels or object receivers determine the direction of message flow across all systems for messages eBiss consumes)).
    - OUTBOUND process can be recognized by the direction setting "OUTBOUND" of the [[en:kommunikation:kanal:start|ReceiveChannel]] or [[en:prozessdefinition:jobs:jobsteps:kommunikation:backend:backendobjectretrieverex|BackendObjectRetriever]] used in it.
    - Other processes like CleanUp, WebServer etc. which have nothing to do with the actual EDI tasks but should run automatically.

==== Further observations ==== 

    - Identify business logic in the job((see [[en:howtos:businesslogic|Business Logic]])) and the associated [[en:prozessdefinition:variablendefinition:start|]] and its [[en:prozessdefinition:variablendefinition:verwendungsnachweis:start]](({{:images:sign_warning.png?nolink|}}**Note:** The variable whereabouts shows only the instances at a partner, but not the usage in jobs or mappings! How or where variables are used in mappings and jobs is described in [[en:transformation:mappings:funktionen:verwendungsnachweis]])).
    - {{:images:sign_warning.png?nolink|}}**Note:** Trace all [[en:prozessdefinition:jobs:jobsteps:allgemein:delegatorjob|]] or [[en:prozessdefinition:jobs:jobsteps:allgemein:eventrouter|]]  Paths of the job!
    - Take note of the [[en:prozessdefinition:jobs:jobsteps:allgemein:entityselector|]] and [[en:prozessdefinition:jobs:jobsteps:allgemein:entitytransformer|]] selection strategy settings!
    - Take note of the XPATH expressions in the [[prozessdefinition:jobs:jobsteps:allgemein:messageselector|]]s!
    - Take note of any preselections of the repositories in the [[en:prozessdefinition:jobs:jobsteps:allgemein:entityanalyzer|]]!

===== 3. Identify integration types or channels =====

Identification of integration and involved or effectively used send/receive channels or BackendObjectReceiver/Transmitters and their properties depending on [[en:partnerverwaltung:typset:start|Typsätze]] and fixed channel settings in system, trading or template partners and in fixed defined [[en:prozessdefinition:jobs:jobsteps:kommunikation:channelsender|]].

{{:images:sign_warning.png?nolink|}}**Note:** In addition to [[en:kommunikation:kanal:start]], there are also alternative integrations via [[en:prozessdefinition:jobs:jobsteps:kommunikation:backend:start|BackendObjektIntegrationen]] see [[en:ueberblick:integration:integrationsarten|]]. These integrations can be recognized by the corresponding associated job objects and variable instances on the system partner.

{{:images:sign_warning.png?nolink|}}**Note:** The grouping possibilities in the eBiss Grid-View is very helpful to get an overview of the set endpoints (the system endpoints, which are defined in the channels, are excellent to outline the EDI landscape and to recognize the involved systems). Attention: Backend integrations are defined differently.

===== 4. Identify message boxes =====

Identification of the required message box and their characteristics((Here also the grouping according to kind(direction) lends itself.)). The effectively needed message boxes are to be considered in direct dependence with the needed channels((Exceptions are message boxes which are used for other purposes adhoc. These are usually only defined in the [[en:prozessdefinition:jobs:jobsteps:allgemein:entitymessagecreator|MessageEntityCreator]]s within the jobs)).

===== 5. Identify (standard template) partners =====

Identification of the TadingPartner templates and their [[en:partnerverwaltung:typset:start]] 

{{:images:sign_warning.png?nolink|}}**Note:** Use where-used list of TemplatePartners!

===== 6. Identify mapping definitions =====

Identification of the required mappings(({{:images:sign_warning.png?nolink|}}**Note:** Use mapping references Show in context menu!)) via the dependencies in [[en:partnerverwaltung:typset:start|typeset definitions]] or [[en:prozessdefinition:jobs:jobsteps:allgemein:entitytransformer|]]

===== 7. Identify repositories =====

Identification of required [[en:prozessdefinition:repositorien:entitaetstyp:start]] and their components((See: [[en:prozessdefinition:repositorien:er]])) depending on required [[en:transformation:mappings:start|]] and set [[en:partnerverwaltung:typset:start|]]

===== 8. Identify interface types =====

Identification of the required plugins depending on the required [[en:prozessdefinition:repositorien:entitaetstyp:start]]((It is not easily possible to identify the DLL file by entity name. This also works in essence only if [[en:howtos:namingconventions]] has been taken into account. Otherwise the integration specific DLLs have to be **reverse engineered** with suitable methods, but the eBiss [[en:programmierung:typbibliotheken:typeditor|]] is perfectly suitable for this)).