This blog will be a continuation of my previous blogs on packaging. I’ve been adding to this blog series incrementally as I learn more tips which have saved me time in the past. Here are a few tips I’ve picked up since the last blog post that will hopefully help save you some time when creating packages in the future. They mainly revolve around Items and ItemTypes which require additional steps or have a dependency which could be overlooked.
Order Of Operations
This is the current order in which the admin ItemTypes are imported when added to an Innovator instance. This list is current as of 12 SP18, but future releases will include more ItemTypes which will change this order. You can see the order moves generally from things with few or no dependencies, to items with more dependencies.
|
1. List |
2. Sequence |
3. Revision |
|
4. Variable |
5. Identity |
6. Member |
|
7. User |
8. Permission |
9. Method |
|
10. User Message |
11. Email Message |
12. Action |
|
13. Report |
14. Form |
15. Workflow Map |
|
16. LifeCycle Map |
17. Grid |
18. ItemType |
|
19. RelationshipType |
20. Field |
21. Property |
|
22. View |
23. SQL |
24. Metric |
|
25. Chart |
26. Dashboard |
27. Query Definition |
|
28. Tree Grid View |
29. CUI CommandBarItem |
30. CUI CommandBarSection |
|
31. Presentation Configuraton |
. . . |
|
Permissions
When creating packages which include ItemTypes and LifeCycles, it’s important to make sure you include any custom permissions you may have created. Permissions can be added directly to packages but will fail if your target system does not have the same identities listed in your permissions.
Identities
Speaking of identities, they have an interesting use case as well. Often times when you package an Identity, it contains member objects which reference other identities, groups, or users. To avoid this I recommend going into the exported AML and deleting all of the member relationships. This will ensure that your identities and data model will import cleanly.
Once imported you’ll need to go into the target system and link the desired members to your identities. It’s very likely you might have different users and groups in your development and target environments, so reconfiguring your member relationships is a good idea regardless.
Users
Normally creating an import package is about moving functionality, and not “data” such as Users. There are a few things to look out for if you do want to import Users.
When importing users, an alias Identity will be created automatically. This means that the resulting alias Identity will have a different GUID in the target system than it did in the development system. This can result to conflicts if you have references to alias Identities.
If you need to transport users with your solution, then these users should be in a separate sub package of your solution. This will still cause the issue with alias identities with different GUIDs if these are referenced in custom group Identities of your solution package.
Conclusion
These are just a few things I’ve picked up over the past few months while moving development work between environments. If you run into packaging issues please look for help on our forums! I try and include issues that have been posted on the forums before in this series to help future users. If you have a tip that could save people time, please leave it below in the comments.