The actual tasks of building out a IBPM process includes constructing BPDs, services, reports, Coachs and other related artifacts. Generically, this is called development. This section touches on some of the areas associated with the act of developing a IBPM based solution.
Sharing projects with others
It is not uncommon to want to share projects with others. In the IBPM environment, this is normally achieved without any work as all the artifacts are saved in the Process Center so that all users attached to the same Process Center can see the same views of the data. If multiple Process Centers are being used then it may, on rare occasion, be desirable to export a project from one Process Center and import it into another. This can be easily achieved with the export capability. First a snapshot must be created. On the Process Center page, selecting an application will show its snapshots. From here, an export operation can be performed.
This will prompt for a destination for a file that will contain the exported resources. The file suffix for exported files is ".
To import a process, on the main page for the Process Apps in the Process Center, an Import Process App link can be found.
Selecting this produces a wizard for importing the project.
Naming conventions and recommendations
IBPM is pleasantly un-restrictive on names that may be given to artifacts. In fact, we can give multiple different types of artifacts the same name if desired. The type of artifact acts as the discriminator.
When an artifact is exposed for starting such as a BPD or a service, the name of that artifact is what shows up in the menu. As such, it is a good idea to give the artifact a name that you wish to publicly expose. For example, in the following diagram we have exposed three BPDs. The first two have poor names but the third gives an indication of what it does.
The instance name of a process is also exposed. The value of the Process Instance is set in the BPD overview and shows up on Process Portal tables.
Process App name recommendations
When a new Process App is created, an acronym value is supplied. This can be up to seven characters in length. My recommendation for a naming convention on these is:
where A-Z is a single character and YYMMDD is the current year/month/day. For example, if I needed a new Process App, I might give it the name:
By using this technique, we have a good chance that we won't have a collision.
When a BPD or a service is written it is still fresh in the writers mind and is believed to be able to be remembered in the future. That is never the case and the original writer may no longer be around in the future. Documenting the solution as it is built is vital. It may seem like wasted effort and, in many cases, the documentation is indeed never read again … however … if it is read and understood just once in the future, it can have paid for itself over and over again. Most of the artifacts associated with IBPM have a documentation section associated with them. This is a text input area where information can be entered that does not affect the operation of the solution. When a IBPM PD user subsequently visits the artifacts, the documentation previously entered can be re-read.
At this time there is no known way to produce a report from the documentation but that normally acceptable. I'm not sure what it would mean to generate a report of parallel branches of a process flow and have them read serially in a PDF document.