The purpose of an EDMbinaryPackage is to support:
- Transfer and synchronization of models and other database subsets between hosts
- Backup of models and other database subsets
The EDMbinaryPackage will be officially available from edmcore version v602.207.85
An EDMbinaryPackage will be stored as one directory. All files in the directory will have the same name as in the source DB.
The default name of an EDMbinaryPackage has the following syntax:
- DirectoryPathAndName/EDM.dbName/MmodelIndex/SourceRepositoryName.SourceModelName.BIN
Example: “C:\Files\ServerClientsFiles\EDM.db1.M22.DataRepository.PdmModel1.BIN”
The “SourceRepositoryName.SourceModelName” can be replaced by a given name. Example: C:\Files\ServerClientsFiles\EDM.db1.M22.MyPDMmodel.BIN
Another important functionality of the EDMbinaryPackage, is backup of models. The export function will only block updates of the actual model in a “very short write transaction”, except for this small time slot, the model will be free to use for other appservers (clients).
To have a consistent “save point/backup” of a set of dependent models, it may be useful to handle more models in one EDMbinaryPackage
Q & A
I'm currently testing from SSP (so via edmi). Later on may be XPX wrappers will be useful as well.
Some questions about logic/parameters:
'newModelIndex' in import parameters - what is it for?
Q:- 'newModelIndex' in import parameters - what is it for? I supposed that in my use case both model instanceId and entity instanceIds should be equal to those in original model (but for other use cases remapping ids might be useful)
A: This functionality is for importing the BinaryPackage to another modelIndex than the source, i.e., all instances in the model will be modified with the newModelIndex.
How Files 'newer'/'older' filter can be used in practice?
Q: how Files 'newer'/'older' filter can be used in practice? I could probably export newer files only - but I suspect importing will erase all existing files, and there will be no option like 'append' those newer files to existing model... Or may be idea is to export BinaryPackage, merge it with another (newer) BinaryPackage and then import back into EDM?
A: Origninally this functionality was decided after a discussion with a user when he mentioned that it would be useful to only import “files that have been modified since last import”. It may be required with more options for this function. The BinaryPackage will contain a separate file where all files in the BinaryPackage will be listed according to the lastUpdate date. Hence it is easy to implement functions like NewerThan, OlderThan, FilesNotInTarget, ..?
Is it possible to reuse existing model GUID (and probably TC) ?
Q: is it possible to reuse existing model GUID (and probably TC) ?
A: All data in the edm_model object will be kept. That includes GUID, TC, ..
When option 'DELETE_EXISTING_...' is not specified and model already exists, will import fail or will append to model?
Q: when option 'DELETE_EXISTING_...' is not specified and model already exists, will import fail or will append to model (though I guess 'appending' has no good meaning here - as we are re-using IDs) ?
A: Import will fail.
I tried to use 'REUSE_INSTANCE_IDS' during importing STEP and it seems to not work
Q: P.S. Aside question - I tried to use 'REUSE_INSTANCE_IDS' during importing STEP and it seems to not work (no errors, but no data imported into model) - is it just incomplete or there are some specific requirements for the STEP content (I just used export STEP with EDM identifiers) ?
A: The implementation is incomplete. Until the implementation is completed and tested, I will implement an error when this option is specified.
Note: Exporting/importing a BinaryPackage from an SSP requires the BinaryPackage to be located in the “EDM_SERVER_CLIENTS_FILES_PATH” directory.
Using emiRemoteExport/ImportBinaryPackage, the BinaryPackage may be located in the caller clients directory or in the EDM_SERVER_CLIENTS_FILES_PATH” directory
When the importing EDMserver system have direct access to the location of the BinaryPackage, renameFile will be used instead of copyFile. An option KEEP_BINARY_PACKAGE may be implemented in case such BinaryPackage should be used by other systems or kept for any other reasons
Use cases for 'Files' filter
Q: Regarding Files filter - this is definitely useful functionality, but two use cases I see for it now, are quite different:
- When using binary export for model/db backup, it would be nice to export only files changed since last backup, but then also need to remove 'deleted' files somehow ?
- For replication scenario - copying fresh copy of model from one EDM DB/server into another, it is also important to avoid copying unchanged files (which often take > 90% of model size) - but in contrast to Backups, target system will have 'old' files only inside EDM DB (not in saved copy of BinaryPackage), so replication code should somehow 'merge' set of 'changed' files from source system with 'old' files already present on target system (and again dealing with 'deleted' files somehow). As I wrote before, one straightforward way of doing it is to first export BinaryPackage on target system and then overwrite all files in it with BinaryPackage exported (with 'newer' files only) from source system, though it seems not very efficient...
A: A BinaryPackage will have a “description file” with all necessary information about file objects, including information about “current existing file objects”. Hence when doing UPDATE_FROM_BINARY_PACKAGE, only “updated” files in binary package will be copied and file objects that are no longer existing I source will be deleted during ImportBinaryPackage operation. Same functionality can be implemented in ExportBinaryPackage for UPDATE_BINARY_PACKAGE operation, hence only new updated file objects will be copied to the existing BinaryPackage and “deleted file objects” will be deleted from the BinaryPackage.
A BinaryPackage will consist of the following files:
- “.BPDESCR” BinaryPackage description
- “.I” and “.D” files, one of each
- Optionally: “.BII”, “.BID”, “.FB” files (one of each) when the model have been updated in write transactions
0 to n number of “.F” files.
- Optionally: “.BII”, “.BID”, “.FB” files (one of each) when the model have been updated in write transactions
- The “.I” ,“.D” , “.BII”, “.BID”, “.FB” files will always be copied in an update operation
- Only “.F” files updated later than corresponding “.F” file in the target model will be copied in an UPDATE operation.
- To keep track of the updates, the BinaryPackage description file may be used to make a “update history” in the target system.
EDMbinaryPackage API
Note: Exporting/importing a BinaryPackage from an SSP requires the BinaryPackage to be located in the “EDM_SERVER_CLIENTS_FILES_PATH” directory.
Using emiRemoteExport/ImportBinaryPackage, the BinaryPackage may be located in the caller clients directory or in the EDM_SERVER_CLIENTS_FILES_PATH” directory
When the importing EDMserver system have direct access to the location of the BinaryPackage, renameFile will be used instead of copyFile. An option KEEP_BINARY_PACKAGE may be implemented in case such BinaryPackage should be used by other systems or kept for any other reasons
/* options for the edmiExportBinaryPackage() and edmiExportBinaryPackage() functions */
#define START_OPTIONS
#define ALL_FILE_OBJECTS 01000
#define NO_FILE_OBJECTS 02000
#define BINARY_PACKAGE_ON_SERVER_FILE_SYSTEM 04000
#define DELETE_EXISTING_BINARY_PACKAGE 010000000
#define FILE_OBJECTS_NEWER_THAN 020000000
#define FILE_OBJECTS_OLDER_THAN 040000000
#define END_OPTIONS
EdmiError _CDECL edmiExportBinaryPackage (SdaiModel modelId,
SdaiString binPackageLocation,
SdaiString binPackageName,
EdmiPackedDate filesNewerThan,
EdmiPackedDate filesOlderThan,
SdaiOptions options);
/* Options in edmiRemoteImportBinaryPackage() function */
#define START_OPTIONS
#define DELETING_EXISTING_MODEL 0100
#define ALL_FILE_OBJECTS 01000
#define NO_FILE_OBJECTS 02000
#define BINARY_PACKAGE_ON_SERVER_FILE_SYSTEM 04000
#define RENAME_IMPORTED_MODEL 010000000
#define FILE_OBJECTS_NEWER_THAN 020000000
#define FILE_OBJECTS_OLDER_THAN 040000000
#define REALLOCATE_IMPORTED_MODEL 0100000000
#define DEFINE_MISSING_ATTR_HASH_TABLES 0200000000
#define END_OPTIONS
EdmiError _CDECL edmiImportBinaryPackage (SdaiString binPackageLocation,
SdaiString newRepositoryName, /* optional */
SdaiString newModelName, /* optional */
SdaiString binPackageName,
EdmiPackedDate filesNewerThan,
EdmiPackedDate filesOlderThan,
SdaiInteger newModelIndex,
SdaiOptions options);
/* Options in edmiRemoteExportBinaryPackage() and function */
#define START_OPTIONS
#define ALL_FILE_OBJECTS 01000
#define NO_FILE_OBJECTS 02000
#define BINARY_PACKAGE_ON_SERVER_FILE_SYSTEM 04000
#define DELETE_EXISTING_BINARY_PACKAGE 010000000
#define FILE_OBJECTS_NEWER_THAN 020000000
#define FILE_OBJECTS_OLDER_THAN 040000000
#define END_OPTIONS
EdmiError _CDECL edmiRemoteExportBinaryPackage (SdaiServerContext serverContextId,
SdaiString repositoryName,
SdaiString modelName,
SdaiString binaryPackageLocation,
SdaiString binaryPackageName, /* optional; default name: "EDM.dbName.MmodelIndex.RepName.ModelName.Bin" */
EdmiPackedDate fileObjectsNewerThan,
EdmiPackedDate fileObjectsOlderThan,
SdaiOptions options,
SdaiInvocationId *edmiInvocationId);
/* Options in edmiRemoteImportBinaryPackage() function */
#define START_OPTIONS
#define DELETING_EXISTING_MODEL 0100
#define ALL_FILE_OBJECTS 01000
#define NO_FILE_OBJECTS 02000
#define BINARY_PACKAGE_ON_SERVER_FILE_SYSTEM 04000
#define RENAME_IMPORTED_MODEL 010000000
#define FILE_OBJECTS_NEWER_THAN 020000000
#define FILE_OBJECTS_OLDER_THAN 040000000
#define REALLOCATE_IMPORTED_MODEL 0100000000
#define DEFINE_MISSING_ATTR_HASH_TABLES 0200000000
#define END_OPTIONS
EdmiError _CDECL edmiRemoteImportBinaryPackage (SdaiServerContext serverContextId,
SdaiString newRepositoryName, /* optional. Default is source repository name */
SdaiString newModelName, /* optional. Default is source model name */
SdaiString binaryPackageLocation,
SdaiString binaryPackageName, /* optional; default name: "EDM.dbName.MmodelIndex.RepName.ModelName.Bin" */
EdmiPackedDate fileObjectsNewerThan, /* optional */
EdmiPackedDate fileObjectsOlderThan, /* optional */
SdaiInteger newModelIndex,
SdaiOptions options,
SdaiInvocationId *edmiInvocationId);