Informatica Schedule调用还是shell调用
  首先介绍下Infomatica Workflow运行的几个选项（Run Options）：
  1，默认的run on demand 依据需求运行(被动的被启动)。
  2，run on intergration service initialization intergration service  启动的时候运行workflow，下次什么时候再运行取决于Schedule Options中的设置。
  3，run on continuously   连续不断的运行，其实就是一直跑，跑完一次后接着跑第二次（该模式用的不常用）。
  对与第一种run on demand，这种运行模式在开发的时候，我们都是会选择改模式的，手动去调用进行测试，自动启动如2，3都是在很稳定的情况下才去让其自己Schedule起来跑应用实际上在应用较少的情况时，或者说只是用Informatica跑独立系统后台数据，如银行的很多系统的数据同步，简单的报表应用。说白了也就那么十几或者说几十个workflow的应用时这时候可以应用shell去调用（指的就是第一中需求时被动启动）这样可以很简单的控制这个系统的数据是否完全正确的跑完，当然这种控制需要去写脚步，对每一步都要有很清晰的
认知，上一步跑玩，开始跑下一步，这步出错了后面的应用哪些是不能继续跑下去的，可以完全用shell来进行控制，自行设定不用在workflow 中过多的关注这些控制（如增加task
Commend，EventWait来加以控制），有益于开发起来简单，因为控制都可以放在shell脚本一次性搞定了，开发人员只要去关注下当前的业务需求即可。

  在选用Schedule的方式时，这时候可以由开发人员自行控制何时调用（到时间自启动，不需要人工干预）这个时候，其实在开发的是开发人员不光需要关注自身业务需求，还需要关注上游数据的获取，以及下游数据的给出，如当跑这个workflow的时候，需要等待什么数据已完成的情况下，还有在自身workflow完成时，要不要给出下游应用信号文件，以便完成下游系统正常的调用取数
  写到这个地方我觉得有点java开发的是控制器的一个原理，其实在没有struts 前就相当于这个地方一直在用schedule一个道理了，什么都是自己来，自己管理自己控制，自己设定好workflow启动时间，自己去获取信号，自己发射信号，在利用shell时，就不一样了，整个控制都交给shell脚本来控制，发出信号文件，等待信号文件，出错处理，预警都是可以交给它这个总的控制器来进行控制，它知道什么时候可以启动是有效的调用，甚至说应用多会节省较多的系统资源（因为不存在某个起着workflow 的只是为了等待某个信号文件）。
还有个好处就是你用shell控制的时候，可以减少人工干预，出错时，你可以把之前产生的信号文件及时的处理掉，不至于让下面的程序产生误导。

  然而有这样的情况，需求每天都是在变的，经常性的有新的需求需要开发，有的需求很独立，需要新建workflow ，有的需要在原来的workflow 上添加或者删除task或者说某个需求它就是指定了在什么时间是要求去数的（如每个月的某一天，当有很多这种情况的时候），简单的用shell去管理控制的时候，压力就有点大了，因为你有可能几天就要去修改下你的shell脚步，你极可能要控制今天哪一个workflow 是不跑的，明天那一个是不跑的。这样也是很麻烦的。办法总是有的，可用读取配置的办法。

  具体如何应用这两种调用方式，还是要看实际应用，大致是这样的系统只是很简单的后台取数，很稳定，新需求不多，上线后变更不大的，这是时候选择用shell来调用是很方便的你可以把系统几乎所有的后台控制都可以很爽地写到一个总控中（shell脚本），调用步骤，何时调用，前期信号判断，后期发送信号，出错处理，预警，都能交给它来帮你处理了。在需求经常变化，不固定，系统应用较多时，交给informatica的Schedule来帮你调度，发送，接受信号都是你自己在开发的时候要很关注的事情，调用只要你设定好Schedule时间其余的就交给Informatica 了。