Hello, I am still in the early learning stages as an ARIS administrator. Our user group is also new to ARIS. Our library of models as well as our ARIS environment, structure, etc., was all done by third parties. We are on ARIS Enterprise cloud, version 10.0.21. We have a training database so users are using that to practice building their models and getting familiar with ARIS. I received a question from one of the users that is an ARIS Connect Designer. He wants to know if it is possible to copy a model between databases. This way if they get the model built the way they want it in the training db, they don't have to redo it in the real db. I have searched high and low, and the answer seems to be yes, but I cannot find any detailed documentation on how to do it. I would also appreciate any input regarding best practices around this. What options are there for copy/paste between databases, or is it an export/import function? What role(s) should perform this function (Designer, or have to be an Admin?)?
We have a special name for copying a model from one ARIS database to another one: Merge ARIS databases.Described on the help page of ARIS Architect: ARIS Help (ariscloud.com). Merging ARIS data is a very powerful feature as it helps a lot to preserve all data in the target database which is assigned, linked, or associated to the selected item, such as one or more models, groups or objects.
I guess you couldn't find it in the ARIS Help opened in your browser from ARIS portal because merging requires ARIS Architect, the Java-based ARIS client product. And that product comes with its own help file. If you are have licensed ARIS Architect you probably want to bookmark its help page (also available via F1 key from Architect). example here on my company's SR23: https://my.ariscloud.com/abs/help/en/handling/ba/#/index/en/1 You just copy the bold part from above and add it right behind your ARIS Cloud Enterprise server URL (without the tenant name, such as #default).
Another option to copy an ARIS model to another database is much less convenient: exporting an ARIS model into an XML file, or in the case of BPMN-compatible model type, you can export a model into the BPMN2 serialization format, enabling import into other BPMN-compatible tools: ARIS Help (ariscloud.com). This way exports only the pure model information including all its objects, but no links to other ARIS items in your source database, no user privileges etc.
With exporting an ARIS model as (encrypted *) XML file, you can only import the pure model information into another database, whereas merging allows you to copy much more data.
*) XML file exports are encrypted by default, so that only ARIS can import it. If your user acount has assigned the ARIS Access license the XML file would be saved unencrypted.
Runé, thank you, this was very helpful! The Architect help was resulting in an error, but I was able to get to it using the link you sent me. I found what I was doing wrong (trying to drop the model from source db in to a specific folder of the target db). Newbie mistake :)
I have been using the exporting option, but the merge seems much more convenient,
I have an Architect licence, ARIS Advance and the java client product and apparently I have all the required permissions. However, though I am following the ARIS Help instructions, it does not work. The Merge Wizard doesn't open. Is there any other requirement I may be overviewing. Do you have ARIS Advance or ARIS Professional licence?
The only caveat here is that if they built a model in training db with "entire method", but you use a more limited filter in your production - all the elemets that are not in your production filter will be grayed out and unavailable for edit/delete. You as administrator will have to log in with Entire method into prod and remove elements that don't exist in your production filter
Here is another caveat particularly in connection with exporting from "Training sandbox" databases: The objects in those databases tend to be outside of quality assurance. E. g. role objects or other library objects you use (or even create) in a process model are not identical to those in your production database. With merging your model content from training to production database you are likely to have to clean up and replace the sandbox-created objects with the proper ones from production. So consider well the identity of objects when merging content between databases.
It is not uncommon that customers use separate databases for developing to-be content before merging that upon approval to a dedicated database used for publication. Some constellations of governance requirements may make such a multi-database approach necessary.
But even in these scenarios they will have yet another database for training purposes where nothing will ever leave the database in the direction of productive content - as tempting as the idea may be. It is just too error-prone when people in the proper database (accidentally) start reusing the debris merged from the training DB.
