I’m trying out Iceberg, the workflow automation platform. In my previous post I decided what application I was going to build, and wrote the first two user stories.
Again, I’m using the Iceberg User Guide to guide me. The first thing that is quite confusing is that the environment within which you are building your application is also the one which displays it – I’m guessing that a later stage creating user-only logins allows you to hide all the configuration options.
I’ve created a new application, and added two new objects – Project and Project Issue. The next thing I want to do is tell the system that these two are related:
Counter-intuitively you do this by modifying the Form for an object rather than the object itself – by adding a field which is of type Select List you create a dropdown field that creates a one-to-many link
Another thing that you immediately notice is that the listbox used to select the relevant object for the other side of the relationship shows all objects in the system (Iceberg out of the box seems to come pre-populated with certain common objects), reinforcing the point that this is a platform / environment rather than just an application framework. I imagine the idea is that everyone within a company or workgroup would look at the same instance of Iceberg and see a common set of inter-linked applications.
The next challenge was to ensure that all ProjectIssues are created with a unique identifier. Traditionally this would be done either with built-in DBMS functionality or a trigger on object creation. Time to open up the Process Designer. (also time to find another small IIS7 issue, documented here).
OK, time to get thoroughly stuck… (see the next post)
