2021:Import or Export Grooper Objects
How can you share Grooper objects, like Content Models, Batch Processes, Batches and more, with other Grooper users?
About
Grooper allows you to export Grooper objects from a Grooper Repository as a zip archive file. You can then bring in those objects into a Grooper Repository (such as one you are not connected to) by importing the zip file.
The process is straightforward, but there are a few things to watch out for.
How To
Export Grooper Objects to a Zip File
Exporting a Single Object
For this example, we have an IP Profile batch named "Sample IP Profile - Layout Data" that we want to export from this Grooper repository and import it into another.
|
|
The following window will appear.
|
|
You will then return to the previous window.
|
|
You can find the zip file wherever you chose to save it. |
Exporting Multiple Objects
You can also easily export multiple objects to a single zip archive. For example, what if we wanted to export the "Sample IP Profile - Layout Data" IP Profile as well as this Batch named "Sample Batch"? |
|
The starting point is much like an export of a single object.
|
|
This will bring up a window allowing you to select multiple objects in your Node Tree.
|
|
|
Exporting Objects with References
Grooper makes use of references in a variety of different ways. Data Fields often reference Data Type extractors to populate fields in a Data Model. A Recognize step in a Batch Process will reference an OCR Profile. References are a fantastic way to get reusability out of the objects you create and configure.
When you export an object referencing an external object (one that is in a different location in the Node Tree) by default, Grooper will also include that object in zip file export. However, depending on your situation, you may want to export the referenced object or you may not.
Note, the "Docket Number" Data Field uses a Read Zone extractor in order to populate the field. The Read Zone extractor allows you to (among other things) anchor a rectangular zone from a text label on the document. Any text falling within that zone will be extracted as the Data Field's result. The Read Zone extractor also allows you to optionally re-process the text's OCR result with the OCR Profile property.
|
|
|
|
Notice in the "References to Include" window the referenced OCR Profile named "Teseract Cell OCR" is included in this list of items. This window will list all referenced objects of the object (or objects) you have selected for export. By default the box next to these references is checked, indicating it will be included in the export. However, if you wish to exclude a referenced object from the export, simply uncheck the box next to the listed object. |
Importing Grooper Objects from a Zip File
If you wish to follow along with this tutorial, you may import the zip archive file linked below into your Grooper Repository.
- Version 2.80 Media:Sample Grooper Export (2.80).zip
- Version 2.90 Media:Sample Grooper Export (2.90).zip
- Version 2021 Media:Sample Grooper Export (2021).zip
Importing All Objects from a Zip Zile
This tutorial will start us off with the most basic import. This import will bring all Grooper objects into your Grooper Repository, even if copies of those objects exist in your repository. We will look at how to deal with selectively importing objects and resolving duplicate object conflicts in the next tab of this tutorial.
|
|
|
|
All objects in that zip file will be copied to your Grooper Repository. The objects imported for our example are highlighted. Their property information will be stored in this repository's database, and their files will be stored in the associated filestore. |
Selectively Importing Objects and Resolving Duplicate Objects
As mentioned before, by default importing a Grooper zip will overwrite an object if it already exists in the Node Tree. If the two objects share the same GUID (globally unique identifier), the object's property configurations will be replaced with those of the object in the zip file.
FYI |
Note, this means the two objects could have different names but the same GUID. Grooper really cares about GUID matching up, not the names. If the GUID matches, it will overwrite the object and rename it to whatever it's name is in the zip file. The reverse is true as well. They could share the same name but different GUIDs. If the names are the same, but the GUIDs are different, the object in the zip will be imported with a unique name and the object in the Node Tree will remain unchanged. If the imported object is imported in the same node tree level (i.e. there is an IP Profile in the IP Profiles folder named "Layout Data" and the imported object is also an IP Profile with the same name going in the same folder) a number will be tacked on to the imported object's name to force a unique name (i.e. "Layout Data (1)"). |
This may be what you want to do, or this may not. Grooper gives you the capability to choose how you want to resolve these conflicts through the Import Options property.
|
|||
The Condition column will let you know whether or not the object exists in the Grooper Repository. It will list No Issue if the item in the list does not exist in the repository. It will list This item already exists. if it does. |
|||
|
|||
Use the dropdown menu to choose how you want to resolve the duplicate file conflict. This can be one of three choices.
|
|||
|
|||
Rather than overwriting the object, a copy named "Sample IP Profile - Layout Data (1)" is created! |