The file structure of v9 is a much needed improvement on v7. Wrapping all of the xml files in a compressed xep was not great and the issues I describe in this blog of saving issues (when the designer throws an exception) are partly down to BPM having to fully update and compress the contents of the singe xep or xel.
In v9 the objects/artifacts of a BPM procedure (now known as a project) are saved as their own seperate files in a useful Solution > Project directory structure. Projects (procedures) now have a parent ‘Solution’ container meaning that several projects and libraries can be grouped together as a solution. For the visual studio developer, this new file structure will seem very familiar. The advantage of this new Solution container is that you can farm out your projects to different developers and bring them back into the main solution at a later point (as the scope of project objects/artifacts tends to be at the project level as opposed to the solution level) .
The objects/artifacts of a project are now saved as self contained files. Forms, connections, business objects, processes, roles and flags are all saved to the project directory as individual files. Here is a quick picture of what a solution directory listing may look like for v9:
c:\MySolution\myProject\MetastormDefault.Connection (this is the Metastorm database)
c:\MySolution\myProject\Expense.process (what we used to know as the map)
c:\MySolution\myProject\Role.Role (contains all roles)
c:\MySolution\myProject\EmployeeList.mbo (a business object from an employee table)
With the structure being this way, the historical problem of having multiple developers work on different parts of a process may now be a thing of the past.
The Metastorm designer mirrors the file structure in its tree based artifact menu. The tree view of your solution now shows your artifacts in a very organised, alphatbetical order which is an improvement of the old way of viewing the map artifacts (forms, stages, actions etc). This new way of viewing your projects is a lot closer to how the other enterprise level BPM tools display theirs.
Another point to mention is that Libraries can be created as part of a solution that contains projects already. When the solution is deployed to the standard Metastorm BPM server repository included library is made available to other procedures being designed. Through the repository viewer in designer you can reference an existing library in your current solution by clicking on the deployed library.
Below is the structure your project artifacts available in the designer:
Solution (New Wrapper for procedures for applications that stretch accross multiple projects)
Referenced Libraries (xel – You inherit all of the libraries objects)
Admin Form Groups
Connections (allow connections to LDAP directories, web services and databases)
MetastormDefault (essentially the DSN properties for Metastorm database)
Used By Action
Used By Stage
Metastorm Business Objects
ProcessContext (eFolder information from Metastorm database)
ProcessData (custom variables)
MyEmployeesListTable (accessed like MyEmployeesListTable.EmployeeAge)
Used By Process (as a sub procedure)
Used By Form
Used By Stage
Used By Action
Solution Tables (external tables)
Process artifacts (forms for example) can be exported as templates, which is great for saving a forms standard layout.