Our 3D CAD supplier models have been moved to 3Dfindit.com, the new visual search engine for 3D CAD, CAE & BIM models.
You can log in there with your existing account of this site.
The content remains free of charge.
No replication/synchronization is needed:
As of V9.08 there is no synchronization of CADENAS_DATA needed. At the local site, where the PARTapplicationServer is installed, access times then even will be a bit faster in compare to direct file access to 23d-libs.
At remote locations the speed should be Ok despite of accessing the headquarter. The main problem is the loading of large parts/ZJVs (also see caching with Squid).
With V9.08 clients further on directly connect to the LinkDB (in the same way as in current implementations).
Searching with filters and roles will be faster now from remote sites, although the LinkDB is not connected via AppServer. This is achieved by adding the LinkDB content to the full-text search index. That means, the LinkDB content has also to be updated by the "Nightly Update" (see Section 5.8.13, “Automated and cyclical update of data ” in PARTsolutions / PARTcommunity4Enterprise - Administration Manual).
Create LinkDB search indexes (ERP Lucene indexes)
Time exposure for an initial filling: 100.000 Datasets about 25 min. per role.[4]
The LinkDB search index should be created again or updateed when projects or roles changed. (In order to manually execute commands also see Section 1.1.4.4.6.2, “Context menu commands in detail ” in PARTsolutions / PARTcommunity4Enterprise - Administration Manual.)
Per
scripting, you can also perform incremental updates ($CADENAS_SETUP/scripts/erp/nightupdate_erp.vbb
).
For the pool path there are several options available:
Pool directory on server, but with different share than CADENAS_DATA
CADENAS_DATA=/server/freigabe/data Poolverzeichnis=/server/freigabe2/data/pool
CADENAS_DATA pointing on a dummy directory. Then the pool directory can point to the server.
CADENAS_DATA=c:/dummydir Poolverzeichnis=/server/freigabe/data/pool
The only important thing is, that the pool directory is not under CADENAS_DATA; because then RemoteFileSystem is responsible for the pool directory; meaning that it is "ReadOnly".
SharedIndex (partsol.cfg -> [PARTindex] -> SharedIndexDir) may not be configured on the server. Constant net access would slow down the search.
When using an AppServer, the SharedIndex may not be on CADENAS_DATA.
The following key puts the Shared Index locally.
[PARTindex] SharedIndexDir(AppClient)=$CADENAS_USER/shared
Ports for PARTapplicationServer and SearchServer, configured in the configuration files differ by default, so that it is possible to drive V9.8 and <= V9.7 parallel on one server, which could happen in the changeover phase.
Available functions (with V9.08 SP0)
The PARTapplicationServer is providing the complete 23d-libs file system to PARTsolutions. That means:
For the most used functions APIs are implemented in the PARTapplicationServer, in order to make it faster. But not yet for all functions. That means, a few functions will currently be disabled in AppServer mode, meaning all functions, which write on 23d-libs, because it's a read-only file system.
Available with all features (the list contains the main points):
Not available, because for this writing permission is needed:
No write access possible because the access to the catalogs is done by the AppServer. To be able to perform the check-in, you must enable the direct access to the server for this client
eCATALOGsolutions-PARTdataManager Configurator mode
Edit table: This menu item is not displayed by default, but is used by some customers.
SharedPool for Document scan: Here the path should be set to the local user directory.
|
For external access from PARTsolutions to the PARTapplicationServer from secondary locations SQUID can be optionally installed. Squid is free software, which is installed at customer site. For the PARTapplicationServer access HTTP is used. All ever loaded files are in the local cache.
Squid checks whether files are really up-to-date.
The cache can be initially filled via VBS scripting for certain catalogs. And via VBS command the files are nightly grabbed and copied in a temp-directory. Thereby the cache is filled.
Caching only works, when the head quarter is online.
This is not a real restriction, because the headquarter has to be online for LinkDB calls anyway. Also using earlier versions, PARTsolutions cannot be used remotely without access to the headquarter server.
When changing to the new PARTsolutions PARTapplicationServer, then also company internal parts, including LinkDB colors and role selection can displayed.
API: Via API inhouse third party systems like PDM systems for example can access the PARTapplicationServer. (Therefor an extra license is needed.)
Due to PARTapplicationServer's own caching an additional Windows File Caching is not necessary.[5] [6] It possibly can slow down the search on the server significantly.
Slowed down search when using a virtual disk
When testing on a virtual machine you have to consider, that the C disk on the server is not really local, but rather is in the network. (When testing on a real C disk the speed is possibly higher.)
When caching is used, all search indices are saved on the PARTapplicationServer. This makes sense, because accessing a local resource is faster.
Using a VM the process differs: Caching happens from the net into the net and then parts are loaded from there. This could act as a brake.
Better use an ESX host with local disks, still better an ESX host with local SSDs. In this way search times can be reduced again, especially if a search results in as many parts that they do not fit into the memory. Furthermore then there is no network bottleneck.