[isv]

Hi,

We've had an idea about using OP in an unconventional way that would allow us to breath new life into an old sales order processing system.

We would like to use OP to manage a very large number of small 'projects'. Each project would be a representation of an order within a legacy sales order processing system and OP will be used to enhance our ability to schedule resources against each order.

Completely under software control I need to be able to create projects, resources, tasks etc. and periodically print schedules and, potentially, then use data from inside OP to update the existing ERP system. It is likely that OP would be running completely 'hands-free' on a dedicated machine whilst being totally driven via AppleScript.

We're happy that we can get our data in/out of the ERP system via AppleScript but having taken a quick look at the OP script library it is unclear to me how we could automate the creation of projects.

Another concern is that we will need to create something like 10,000 projects a year... Fortunately each project is tiny with less than 100 tasks and few resources... But we would essentially be using OP as an extension to an existing application and it would be running AppleScript 24x7 to load each project in succession, perform updates, export/print schedules etc.

Can someone with greater knowledge of OP's scripting support advise me on its suitability for this task? Any reason why OP could not handle 10,000 projects in a file system? Thanks!

Alan.

[Lizard]

OmniPlan's scripting support will probably handle this, but it hasn't really been tested in that type of scenario.

All the properties of tasks and resources are scriptable at this point. (Let me know if something isn't!) Exporting is scriptable; however filtering on export is not. Printing is not scriptable.

There are two approaches (and possibly a hybrid, depending on the relationship between your projects).

1) Each of your projects in a separate document. Tell OmniPlan "make new document" and it will create a new document with one project in it. This will probably give you better performance. However, it does mean you'll have 10,000 files on your server. Also, you won't be able to level resources across projects automatically. (You could set up a script to approximate leveling across projects -- let me know if you need details.)
If your projects are relatively independent, this is probably the way to go. If you need to export one project, without all the others, this is the way you must do it, since filtering on export is not scriptable. In this scenario, you should be careful to close documents when you're done with them. OmniPlan cannot handle having all 10,000 documents open at once.

2) All of your projects in one OmniPlan document. An OmniPlan document technically only has one project, but that project could have 10,000 top-level task groups, one for each of your projects. This would allow you to level resources across your entire system. This will probably be slower, though -- even to update one task, let alone making changes that affect the whole document. This is the way to go if 10,000 files is a problem, or if you must level across the whole system, and can't approximate it by leveling each project in succession, and subtracting its schedule from the next project.

3) If there are logical sub-groupings of your projects -- by geographic region, by manager, by start date, whatever makes sense for you -- you could use a hybrid approach, with 100 documents, each containing 100 of your projects as a top-level task group. This might give you the best of both worlds, or the worst, depending on the exact nature of your data.

[Lizard]

I said above that exporting is scriptable, but printing isn't. Since export creates relatively standard file formats (JPEG, HTML, etc.), you could tell OmniPlan to export to such a file, and then tell Finder to do the printing.

[isv]

Thanks for the response. We will go with Option 1) above and have each project in its own file.

I'm going to do some experimentation with AppleScript and see what performance is like etc.

Alan.