I’ve mentioned in previous posts (1, 2, 3, 4) that I’ve been having a small play with Iceberg, the workflow automation system from Fractis.
Their tagline is “Build Workflow Powered Applications Without Coding”, an appealing concept to many. So how well do I think they have achieved it?
In terms of relatively straightforward applications, the platform is certainly capable of a fast development of data, forms and processes, as evidenced by the growing list of sample applications, and for many cases, especially in smaller businesses, or small teams, that may be enough to get some real benefit. In this area it is particularly interesting that they now have a hosted offering too.
For larger businesses or more complex processes there are still some things I would like to see them do:
I’d like to see the web services integration completed – at present Iceberg can consume web services but the ability to expose your workflow to other applications as a web service has not been released.
The ability to create new dashboard controls (if necessary by programming)
Some consideration of deployment issues – it’s great to be able to iteratively tune an Iceberg application, and in a small enough team it might be possible to do that “on the fly”. But in a larger group it’s important to manage the transition through test into live. I’m sure there are ways to address this at a database level, but if you have the skills in your organisation to do this, how much do you want to be locked into a platform?
Considering that the platform has only been around a few months, I think what they have done is impressive – I’ll be watching to see how it progresses.
I’m trying out Iceberg, the workflow automation platform. In previousposts I described adding some basic forms, views and processes in the context of a sample application.
Today I’ve been experimenting with the security model. It seems both complex and powerful, with the downside that the online help seems to be only 25% populated in this area. Here’s what I’ve been able to work out:
Access Control lists (ACL) – every object (optionally) has an ACL which can control Browse, Read, Write, Delete, Change Owner and Change Permissions rights. A user can be associated with a given ACL by means of direct allocation or via allocation of a relevant Groups, Role or Profile.
Groups – A way of aggregating Users, other Groups, Roles or Profiles
Roles – an application-specific way of assigning rights to forms, views, lists, tabs, controls and actions – it seems this is the main way to customise the look and feel of Iceberg based on user login. Strangely you can only assign Users to a Role, not Groups.
Profiles – are associated with a specific object, and seem to be a way of controlling what lists of related objects a user can see when looking at a specific object form. What I can’t find is how you assign someone to a profile!
I’m trying out Iceberg, the workflow automation platform. In my last post I described starting to build an application, based on this outline specification. I had just got to the point of trying to meet the first acceptance criterion on the first user story (all Project Issues must be uniquely identifiable) when I came to a grinding halt.
The line I started pursuing was to have some kind of global object in which I could store the last used value for a ProjectIssue. I know this is potentially risky in a multi-user environment, but apart from that I have not (yet) been able to find out how Iceberg would allow you to access a global object in the Process Designer.
A fortuitous search on the Iceberg Support site led me to the video below, on how to implement a unique ID.
This will probably be enough for our purposes right now – certainly to be sure every Project Issue is uniquely identified within the system. It does mean that if I have multiple projects in the system then sequential issue IDs may be spread over several projects, but the immediate requirement does not require that the Issues for a given project follow a sequential hierarchy – a timely reminder to myself of YAGNI!
This was the only real issue, and once this was cracked, it didn’t take long to add a couple of process steps to set default values for fields. This first user story is essentially about creating, browsing and editing data, functions which are inherent in the Iceberg environment - so first story done! The second story, as currently written also implies only browse and edit, so is met by what we have done so far.
This will probably suffice for an initial look at how easy it is to use the basic Iceberg functionality - the next things to do are more about refined analysis of the specific application than testing the environment.
Having successfuly installed the platform on my laptop I want to start building something. Of course, the two key questions before building any software (assuming the “Why?” in this case) are “What?” and “How?”.
For the “How?”, Iceberg provide a good overview on their support pages, which in essence boils down to:
Create the application
Create the business objects
Create relationships between objects
Create forms
Create views
Add behaviour and workflow
Security and permissions
Connectivity
For the “What?”, I’m going to build a Project Issue Tracker for use in a Prince2 project environment. I shall start by creating some user stories, linked from this wiki page.
Iceberg offer an “all in one” installer using the Cassini webserver, or for more complex installs you can download a zip file with the web application and a configuration script. As I already have SQLExpress and IIS7 in my laptop I chose the latter.
The setup instructions are very clear, and follow the normal pattern – set up a database and database user, install the web application to a virtual directory on the web server, make sure all users and permissions are correct,
I encountered three small problems during the setup, two of which were answered on the Iceberg Forums (1, 2), and a third because the the default configuration of SQLExpress does not have named pipes enabled. In other words the sort of things which always pop up with setting up web applications.
Having fixed all of those I was presented with the login screen.
This Read/Write Web article led me to Iceberg, a product from Irish company Fractis which aims to make it possible for non-programmers to rapidly assemble business workflow applications.
The applicationn, now at version 2.1, is based on ASP.NET and SQL Server, and is available as a free download. Licensing is free for non-profits or for up to 5 business users. A hosted version is available starting at $40/month for up to 5 users.
Users are encourage to upload their applications to the Iceberg site, either for free re-use or for sale.
The Read/Write web article points to their first look at the beta, in July 2007, and identifies similarities to and differences from Coghead, Salesforce AppExchange and BungeeConnect. Another alternative which I have come across previously is PAT from British company Ninth Wave.
Over the next few days I’m going to try building a simple application using Iceberg and will post my findings here.
Cleaning up iTunes plist XML:
Two-pass approach - changing the iTunes plist format to a clean XML hieratrchy and then processing that
Keywords: XML, XSL, iTunes
Unless otherwise expressly stated, all original material of whatever nature created by Julian Elve and included in this weblog and any related pages is licensed under a Creative Commons License.
Facebook
