前言：

        金三银四，开年第一篇我们来介绍下，怎么在加密情况下运行我们的kettle作业及任务。无疑现在所有企业都认识到加密的重要性，加密后的文件在对外传输的时候不能被访问，访问时出现一堆乱码，同时正常的应用软件也会识别不了加密文件，造成软件不能使用，今天来介绍360旗下的奇安信加密对kettle的影响及对应解决办法~

一、加密介绍

        加密状态下，我们在编辑保存任何文件都会被加密，如下图所示kettle文件在编辑保存后会被上锁。其中包括.ktr（转换）.kjb（作业）。

        1、现象       

        然后我们查看下定时调度的日志，如下图所示定时调度对应作业时会被提示

        Error reading information from input stream
        Content is not allowed in prolog.

        ERROR: Kitchen can't continue because the job couldn't be loaded.

        2、原因分析 

        因在加密状态下，对kettle来说这种加密的文件是不能被识别，因为奇安信不允许它识别。

二、破局之法

        1、解题思路

        找到原因，我们可以有两个切入点。

        1、kettle绕过加密，独立出来，即针对kettle文件默认不会加密

        2、kettle和加密软件和解，奇安信对kettle开通绿色通道。

        当然，第一种方法实现难度较大，而且不合格信息安全的要求，kettle也应该被纳入加密范围，保证kettle文件的安全及稳定运行。

        2、实践案例

        显然第二种方法才是正道，因此我们怎么才能和加密软件进行和解呢？那首先得告诉加密软件它需要怎么配合？

        这里就需要我们了解kettle背后运行的逻辑了。

        2.1前端spoon.bat加载原理

        如下图所示我们找到kettle运行的进程，可以发现的是kettle在前端是以javaw.exe的方式运行的。

 

        因此我们需要对 javaw.exe开通绿色通道。所以我们也把javaw.exe开放了授权，因此确实作业可以在前端被调度了。然而不出意外的话就要出意外了....

        2.2 Kitchen.bat定时调度运行原理

        如上图所示，我们将  javaw.exe开通了绿色通道，因此我们在本地执行时是ok的，但是我们后台定时调度是采用Kitchen.bat来运行，此时我们需要分析的是后台定时调度是采用什么方式运行的，因此我们采用同样的方式可监控到后台定时任务是调用的java.exe，因此我们还需要给java.exe开通绿色通道。

        此时我们再看后台运行日志，可看到我们的定时任务成功运行，问题解决，完美~

三、总结

        因此后续不管我们公司装的是哪种加密软件，只需要加密软件对  javaw.exe和 java.exe两个进程放行即可，这也是为啥说kettle是一个纯java的开源软件，好的，今天就到这，散会~