A.1.5 Splitting the Export Zip File

The export zip can be split apart and re-imported separately. For example, you can separate dataobject and project directory into two zip files, and import them. This section explains splitting the export zip files using the example of the Process Analytics project, which is shipped with BAM.

Import will fail if dependent artifacts are missing, so zips must be imported in the correct order. Oracle BAM splits the export zip into separate project categories using a shell script that includes a manifest. The following table includes notes on why certain files are split. Note that gaps in the numeric ordering – this is to allow for future expansion. Note that BPMAnalytics is Process Analytics’s equivalent.

BPMAnalyticsLogicalDOs.zip.31

Contains LogicalDOs for Process Analytics. Calculated fields can be edited here without locking other projects.

HWFAnalyticsLogicalDOs.zip.32

Contains LogicalDOs for Human Workflow (HFW). Shared with Process Analytics and HWF projects.

CaseAnalyticsLogicalDOs.zip.33

Contains LogicalDOs for Case. Used by Process Analytics and Case projects

BPMAnalyticsProject.zip.61

Contains Process Analytics Project artifacts.

bamalertproj.zip

Contains standard seeded alert for Process Analytics, and import order doesn’t matter. Separated from project to more easily change alert definition.

BAMDataObjects.zip

Contains standard BAM DOs (import order doesn’t matter)

BArchDataObjects.zip

Contains standard Business Architecture DOs (import order doesn’t matter)

Versioning

Oracle BAM does not provide any versioning info within the zip file itself. However, here are some options for embedding versioning:
  • Including versioning info within zip file name. This also has the advantage of showing the version of the file that was preseeded in the PreseedingFileHistory data object. The older versions should be removed from preseeding directory, otherwise all versions will be preseeded

  • Include zip file comments. These comments can be set on a per-file basis, so is a good way to set fine-tuned versioning and commenting ability.

Best Practices When Working With Split Export Zip files

These best practices assume that you are aware of the interdependencies between zip files, and that diff computing is not applicable. Source controlling individual files from the export zip is not practical, due to the number of interdependencies Here are some pointers that may help:
  • One person per project. If you need multiple people to work on the same project, we recommend setting up a shared server. Once work is completed, one designated developer can do the source control. You will want to keep detailed source control comments.

  • If needed, you can merge two zip files. Ensure that there are no overlapping artifacts. You can use any zip utility to combine them.

  • When you update a calculated field ensure that you save and update your project queries and views.

  • When you add a physical data object column, ensure that you add the column in the corresponding logical DO, so you will have to also source control. If there are no calculated field or query changes, you do not need to update the project zip file.