30.2.1. Overview

Now the central service PARTapplicationServer can also be used for PARTsolutions and replaces the SearchServer. Up to now it only had been used for CADENAS Apps, PARTcommunity Mobile and for a while as PARTserver backend. Now the same technique is used for PARTsolutions. The user can search catalogs as usual, even if the catalog server is located at another company site. There is only ONE DATA directory.

Use cases for the PARTapplicationServer:

  • Used by CADENAS App (PARTapplicationServer is located on CADENAS site).

  • Used by PARTsolutions V9.8 in order to avoid distribution and synchronization of catalog data (PARTapplicationServer is located at company site).

  • In the future PARTsolutions can also use the CADENAS catalog server. In this way customers can save maintenance expenditure. (Supplier catalogs on the CADENAS-PARTapplicationServer and own parts on an inhouse PARTapplicationServer.)

  • Access from third party systems such as PDM systems for example to the inhouse PARTapplicationServer, in order to show additional information.

  • Access from third party systems such as CAD systems for example to the CADENAS website PARTapplicationServer, in order to directly show CADENAS content from there.

Using the PARTapplicationServer results in the following advantages:

  • Replication of $CADENAS_DATA is obsolete

    The larger the catalogs database, the more time exposure is needed for the replication.

    As of V9.08 catalog data does not have to be replicated to other locations. The replication can be omitted, because the PARTapplicationServer is much faster. If, however, it should also prove advantageous, caching via SQUID is possible at secondary locations in addition.

    Using the PARTapplicationServer makes it possible to only install catalogs at one location and all clients - regardless at which location - access the PARTapplicationServer.

    In so far link speed and latency play a role and thus caching. Caching holds downloaded parts as long as they are obsolete.

    The two following figures compare the multisite installation structure up to V9.07 and as of V9.08:

    • Up to V9.07

      PARTdataManager (clients) directly access $CADENAS_DATA.

      With SearchServer V9.07 - V9.07 structure at large multisite installations

      With SearchServer V9.07 - V9.07 structure at large multisite installations

    • As of V9.08

      PARTdataManager (clients) now indirectly access $CADENAS_DATA via PARTapplicationServer.

      With PARTapplicationServer V9.08 - V9.08 structure at large multisite installations

      With PARTapplicationServer V9.08 - V9.08 structure at large multisite installations

  • Higher security - No user access to $CADENAS_DATA

    The new concept leads to higher security: Direct, file based access to geometries is no longer possible. There is no direct access to $CADENAS_DATA anymore. Thus users do not have to have access rights for $CADENAS_DATA.

  • Direct access to $CADENAS_DATA only by administration

    Administrative applications like PARTadmin directly access the 23d-libs directory with writing permission further on, because these have to perform changes there.

  • PARTapplicationServer also at Single workstation installation

    The PARTapplicationServer is also used for Single workstation installation (automatically started with pdatamgr.exe). This is advantageous, because then the search is outsourced and nevertheless can be used by all programs on the respective computer (PARTdataManager and Seamless for example). Thus more free memory is available, which again enhances the search speed.