powered by CADENAS



6.10.1. Workflow at a glance

You can publish catalogs directly form PARTproject. Different functions for this can be found under the context menu commands Versioning system and Publication.

Versioning system

Versioning system



Publishing happens in 3 basic steps: Upload changes/Execute mapping, QA publishing and Live publishing (where publishing does not have to be necessarily performed immediately after the upload of changes, however, the up-to-dateness of mappings should be ensured before publishing).

  1. Upload changes / Execute ERP Mapping:

    1. Check ERP-Mapping dialog:

      Once executing the context menu command Versioning system -> Upload changed files in directories / projects to the server, the dialog box Check ERP-Mapping is automatically opened (if 1. relevant changes have been made on data and 2. the option Check ERP-Mapping on upload is activated for the catalog). On this also see the notes at the beginning of Section, “ Check ERP-Mapping (Add ERP-Mapping... and Edit ERP-Mapping...) [catalog modeling]”.

      Check ERP-Mapping on upload

      Check ERP-Mapping on upload

      Click on Search, in order to load the published catalog versions and select the most current. Please note: Especially if the option Save selection is activated, nevertheless you have to search for published catalog versions (Live publishing) and select the latest.

      Do not use the saved selection but search again.

      Do not use the saved selection but search again.

      Then perform ERP Mapping for the entire catalog or changed projects. Skipping would make sense only in very limited number of cases, because if this dialog occurs, then the files selected for uploading in fact contain at least one change requiring a new updated mapping.

    2. Update table versions Dialog:

      Update table versions

      Update table versions

      This dialog is shown if tab/tac files have been changed (-> new tab version), but the change in itself does not require a mapping (e.g. new table row added).

      The background is that the tab versions have to be updated in the mapping, if the respective table is already part of the (current) mapping, to ensure that there will not occur any problems during Live Publishing.

      If it is known whether the date displayed in dialog corresponds to the last Live Publishing, confirm with Yes, otherwise click No. In case of doubt always confirm with Yes.

    3. Optional test

      In order to check if nothing is missed or if all tab versions correspond to the local state, after updating the catalog under Publication, execute the context menu command Add ERP mapping. Hereby the mapping is executed for the current state.

      Existing mappings already verified will not be overwritten hereby. That means, if every user correctly made his mappings, there shouldn't be anything to manually verify at this place. Only if something is missing or tab versions do not correspond to the local state, then mappings with "to check" state will occur again.

      This step is not required, however, hereby you can check without performing a Live Publishing if possibly there are mapping problems and solve them before publishing.

  2. QA Publishing:

    The local current state of the user is separately saved as new QA state (in the SVN Server Publishing Branch).

    [Important] Important
    • NOT the state on the server ("Trunk") is primarily used.

      For Details see Section 6.10.5, “ Generate QA catalog... | Publish Live state... ”, in particular Fig. „SVN Server TRUNK and SVN Server Publishing BRANCH“.

    • If there are changes which are not uploaded to the server (context menu command Upload changed files in directories / projects to the server), for the reason mentioned above, they will become part of the QA Publishing nevertheless.

      -> If the user performing a QA Publishing updates the entire catalog before and has no not-updated local changes anymore, then the QA state will become a copy of the current server state (current trunk). In most cases this is the best approach. The mapping file existing at the time of QA Publishing is the file which then later will be used for the Live Publishing.

  3. Live Publishing: The last performed QA Publishing is transferred as Live state. This includes among other things checking of ERP Mapping, transferring data to the Live portal and the CIP generation.

    [Important] Important

    No new data is added to the last QA Publishing. That means changes after the last QA Publishing will not be taken into account. (And should there still be the need of changes for the Live Publishing, a new QA Publishing would have to be performed before.)

Notes concerning update of mapping file

If a user gets the writing permission for a directory, the file mapping.json is also automatically updated. In the meantime another user may work at another directory and when uploading the changes, the mapping file is also adjusted and uploaded.

In fact, the first user has no up-to-date mapping file anymore, what however is not a problem, as long as the paths of the single mappings do not overlap. (And overlappings should not happen, as users cannot get writing permissions for the same directory.)

It is especially important that at the time of QA Publishing the mapping file matches the current (local) state. (A problem would be, for example, to have the current mapping file locally, but only to update a part of the remaining files (e.g. single directories).

So if all changes (included those from other users) shall be published, then you should update the entire catalog in any case before, in order to have them locally.

Note on partial publishing

The mapping process for partial publishing is the same, at least if a mapping is created at each check in. If the mapping is created one-time before publishing, the context menu command Add ERP mapping for partial publication.... has to be executed on the directory/directories. More details can be found under Section 6.10.6, “Partial Publication ”.

Some more notes