Unless you are a customer of Cast Iron, then this post will make very little sense to you. These are the notes I took over and above the book they provided. They are going up here in case I should find myself in the future without access to the corporate wiki.

  • All orchestrations need to begin with a ‘startup activity’ which are blue
  • There are two ports on an appliance
  • data (which is what the client uses)

  • management (which is how you control orchestrations, view logs, etc)

  • Don’t hardcode anything into any parameters, use configuration properties whenever possible (field has a green ball in it). That way you can set / change them on the server without having to re-save and upload your project. Handy for switching between environments
  • Good Practice – Have a HTTP Receive activity as a starting one to be able to trigger job on demand (use a Pick activity to combine it with a different activity, like Poll or Schedule)
  • Good Practice – Split projects by data type (account data, lead data, order data) so you can reload the project and only affect that particular flow
  • If you have HTTP Receive as the starter activity, you can chain orchestrations using HTTP Invoke
  • Enabling persistence on the server is slower, but lets you resume a failed orchestration at the point of failure
  • If you say ‘requires reply’ for an HTTP Receive, then you need to have an HTTP Send Response on the orchestration somewhere
  • Good Practice – Don’t upload directly from studio, instead, export your project and upload it. Big benefit is that you can give something a version number on upload this way.
  • Good Practice – Add comments to everything; it will auto-generate documentation for you
  • Projects are undeployed by default when published
  • Default log level is ‘error’
  • log synchronously removes the lag between something happening and it being recorded, but there is a performance penalty
  • Its a good idea to constrain the number of threads
  • But you have to undeploy to change settings
  • For some database actions, CI orchestrations certain tables and triggers to be created (it provides the SQL)
  • EVERYTHING IN CAST IRON IS XML
  • So almost anything non-standard requires an XSL to transform it
  • Activities are JS, so custom ones can be created
  • Filtering items in XML is done using XPath references
  • Constrain SQL when you want specific data
  • Filter output when you want to split specific data sets into components
  • XPath is case sensitive
  • Most activities have Delivery Rules
  • Exactly once – no duplicates, requires CI custom tables

  • At least once – could have duplicates, doesn’t’t require custom tables, faster

  • Good Practice – use batch delivery
  • The Database activities are scary as they let you dodge the business rules
  • In order to parse and incoming file (csv, xml, other), the schema needs to be known (again, everything is xml under the covers)
  • When you remove an activity, the variables in it are not removed from the project until you goto the variables panel and say ‘remove unused variables’
  • When doing REST style WS calls, expose the optional headers in the mapping panes and put your values in there
  • Good Practice – Create a global error handling orchestration which has a WS Receive starting activity. Centralized the error handling and reporting and makes your main orchestrations much cleaner.
  • When building flat file schemas, use the wizard then tune using the editor