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

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

Functions:

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.
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.

Browser not supported