一般来讲，iLogic开发可分为
|
静态开发 |
通过iLogic搭建网站框架，各栏目静态页面，页面内容管理等 |
|
动态代理 |
通过iLogic的iportal、ishow、ishow等代理进行 |
|
SaaS服务 |
调用iLogic的一些软件即服务的核心技术服务，如全文检索 |
|
产品配置 |
直接使用iLogic平台层的已有功能 |
ILogic的开发调试，建议分成七个级别进行查错：
|
级别 |
描述 |
简单说明 |
知识范围 |
频率 |
排错方式 |
|
一级 |
运行环境错误 |
操作系统异常 apache服务器运行异常 数据库服务器异常 iLogic平台运行不正常 安全防火墙 |
iLogic运行维护方面 |
2% |
检测操作系统 检测apache服务器 检测数据库连接 检测iLogic平台 本地防火墙测试 |
|
二级 |
网页错误 |
1、 Css错误 2、 Html代码错误 3、 浏览器兼容性错误 4、 浏览页未有效刷新 5、 网页Cookie错误 6、 浏览器不稳定* |
Html代码 |
12% |
直接脱离iLogic进行浏览静态网页排错 |
|
三级 |
网页编程错误 |
1、 js报错 2、 ajax及web2.0错误 3、 页面form表单递交/url跳转错误 |
Javascript代码 |
30% |
页面javascript调试 独立服务url调试 … |
|
四级 |
模组开发错误 |
1、 组件定义不正确； 2、 组件服务端嵌入脚本错误 3、 组件服务端逻辑错误 |
iLogic模组手册 |
40% |
iLogic内部一体化合成调试 |
|
五级 |
动态代理错误 |
1、 Iportal错误 2、 ishow错误 3、 icms错误 4、 … |
Gcms服务 |
10% |
Gcms服务调试步骤 |
|
六级 |
数据库错误 |
1、 数据库本身限制，如长度限制、保留字限制、唯一限制等 2、 数据库其他错误，各种错误 |
数据库DBA |
5% |
数据库错误检测和解决办法 |
|
七级 |
ILogic平台级错误 |
1、 跨服务器、跨项目和跨模板 2、 不同场合和不同开发者 3、 同样规律重复出现 |
iLogic平台内核 |
1% |
云升级系统文件 |
原理概述：
在操作系统上，默认运行apache服务器，apache服务器必须同样正确的环境变量配置，就能调用数据库访问引擎，运行iLogic平台；由此决定这些都是基础支持，否则，iLogic就会问题百出。当然，如果访问时要穿越防火墙，防火墙就可以完全控制最终访问到达与否。
典型情况：
譬如操作系统空间满了，进程堆砌太多，权限配置不对，都会带来基本所有程序的问题；
Apache服务器如果环境变量没有加载，就会导致数据库和iLogic程序加载问题，环境变量一般参照rc.local文件；
数据库如果异常，如无法访问，iLogic服务器自然无法运行；
iLogic服务器如果没有正常得到上述配置和支持，问题自然百出；
即使一切正常，如果防火墙配置安全隔断，那也基本无法达达到。
调试方法：
（1） 登录操作系统，用df检测到空间，用ps检测进程，用top查看内存等小号，全方位检测操作系统；
（2） 通过su – publish等，可以进一步检测操作系统权限达到与否；
（3） 通过ps -ef|grep httpd检测apache服务器是否正常运行，访问一个跟iLogic脱离啊开的静态网页如默认首页看其是否正常运行，查看access.log和error.log查看其运行错误报警等；
（4） 如果为了各种情况而手动修改了apache配置文件httpd.conf，请注意修改的目标和原因，并确定修改正确；
（5） 数据库可以直接通过本机直接访问的方式，如mysql的mysql或oracle的sqlplus工具确认连接正常；
（6） 进一步通过publish系统目录下的./config –t查看iLogic是否正确连接数据库，主要要配置好环境变量；
（7） 通过ping工具和publish目录下的./www_contiainer.exe工具检测防火墙的安全达到性；
（8） 进一步通过后台ps -ef查看iLogic进程运行状态，是否均正常；
（9）
用ls –l *.log查看相关日志，有没有超过
（10） 用ls –l查看所有程序和目录的用户属性，除vrtuhost_man_daemon*外一律必须是publish.publish用户和组。
（11） 登录iLogic如果出错继续检测apache错误日志error.log；
参考手册：
具体请参考iLogic运行维护管理方面的资料。
（12） 登录进去进一步检测进程运行状态。
原理概述：
Html规范通过apache服务器传递，客户端浏览器进行解释；Html解释是不经过服务器，更谈不上iLogic服务器的，请注意。
典型情况：
Css问题，文件访问路径问题，html浏览器兼容性问题，一般问题很常见；
最常见是各种浏览器对Cookie支持方式不同，尤其新版浏览器中的Cookie会直接冲掉前面的Cookie，导致cookie丢失或交叉带来各种奇怪的问题，譬如A进ipaas，然后B又登录看产品，B会冲掉A，导致再到A的iPaas就无权查看甚至直接冲掉；
还有由于浏览器缓冲问题，导致没有及时刷新，ajax和web2.0访问如果不重启浏览器基本不会刷新除非强制传入不同url；
还有就是浏览器本身被浏览器自身插件绑架等原因，导致更加求奇怪的情况出现。
调试方法：
（1） 脱离iLogic系统，请选择静态页面进行调试，防止干扰；
（2） 关闭所有浏览器窗口，单独新建该静态页访问测试，防止cookie干扰、缓冲干扰和未知名原因干扰，如果真要同时调试可以选择另外一种浏览器确保Cookie不干扰；
（3） 选择不同浏览器访问，确定是浏览器兼容问题；
（4） 选择不同机器简单看下，确认是否为自己浏览器被绑架的个案；
（5） 寻找美工制作的支持，共同分析css、html规范问题。
参考手册：
请从网上查找相关html网页调试方法，跟iLogic无关。
原理概述：
Javascript作为html中的一个重要部分，同样是通过客户端的浏览器解释，不通过服务器，更不通过iLogic服务器，要注意iLogic服务和javascript处理在网页中分界的地方。
典型情况：
同html一样，最常见是各种浏览器对Cookie支持方式不同，导致cookie丢失或交叉带来各种奇怪的问题；由于浏览器缓冲问题，导致没有及时刷新，ajax和web2.0访问如果不重启浏览器基本不会刷新除非强制传入不同url；浏览器本身被浏览器自身插件绑架等原因，导致更加求奇怪的情况出现。这些解决方法同上且必须先这么执行调试。
Javascript编程错误，一般会在浏览器上左下角出现错误报警；
Form递交逻辑问题如两个表单同时递交，表单配置问题如method=post等；
Ajax或web2.0异步混乱，作为一种异步传递，跟传统程序的执行先后是不一样的；
网页端程序逻辑问题，尤其是ajax异步逻辑，程序逻辑等；
Javascript更容易带来浏览器兼容问题。
调试方法：
（1） 先按照html错误调试方法一样，依次调试，如果不行，继续往下；
（2） 找到跟iLogic服务之间分界的地方，如果可能，请把iLogic服务返回的数据变成静态XML文件，直接提供静态服务，防止iLogic干扰；
（3） 直接二分法加入alert提示，进行页面调试；
（4） 或者选择javascript调试工具，逐步跟踪错误；
（5） 如果出现一些有时行有时不行，请找一个逻辑比你强的工程师一起看一下你的页面上的编程逻辑，千万注意多表单递交、多异步处理的混合；包括要注意父子ie窗口，平行ie窗口之间在某些值传递上可能会有无法继承的逻辑差别；一个页面内框架页的使用，多框架页的使用，需要清晰其逻辑传承关系！
（6）
Form参数递交可以找一个表单传递调试工具，检测传递出去的参数是否与你需要的一致，推荐…
参考手册：
可以建立不同公司的iLogic规范手册并提供参考；
请从网上查找相关javascript网页编程调试方法，一般浏览器自带，请学习js调试方法， iLogic不提供。
原理概述：
iLogic一切都是模板，模板又主要由组件组成，组件可以嵌入各种脚本，这些本身就是一个试错的编程过程；调试好模组，基本完成了主体调试工作。
典型情况：
模组类型选择错误；
模组服务算法配置错误；
模组是否入库设置错误；
嵌入脚本编程错误；
调试方法：
在书写完组件代码后，只要选择 [显示组件名称及取值]的方式合成页面模板，该选择将会让系统分别显示各个组件的算法问题，同时，iLogic将会利用内部的语法检查器对组件代码做一些最基本的检查，如发现错误，会出现提示和报告。
注意：
如果有些参数是从外部表单传递进入，从而影响调试，你完全可以在第一个组件的code处设置这些变量的值，从而继续直接用该方法来调试。
注意：
任何嵌入脚本中的变量，如果没有输出，你可以先确认其是否为全局变量，一旦全局变量，可以在模板html中用${变量名}的方式查看数值。
参考手册：
iLogic模组参考手册中的快速调试部分。
原理概述：
所有模组，一般都是通过云服务框架进行服务，包括iportal/ishow/icms等，哪怕外部定制的程序，这些都是通过gcms提供soap服务完成，因此gcms服务检测和调试要把握。
典型情况：
Gcms发现错误而返回；
外部变化导致gcms无法正常工作；
…
调试方法：
（1） 确保无gcms是提供的静态服务是正常的，这是前提；
（2） 如果发现全部都有问题如无法访问，则证明是gcms配置问题导致；
（3） 如果发现一些个别的问题，请查看gcms服务日志，gcms.log!
（4） 你也可以直接执行服务调试代理，查看gcms.log和debug.log！
（5） 更多的错误，你可以继续查web服务器的error.log，即使都没问题，error.log里面可以查看很多东西！
（6） 最常见包括分解日志doc_disparse_daemon.log、发布日志background_post_daemon.log、版本日志doc_version_daemon.log，你可以直接查看也可以通过ipaas集成界面上的日志分析工具进行；
（7） 这些错误查看方法均集成在ipaas集成开发环境中，实际上还包括其他很多种日志，具体取决于系统版本和授权级别；
（8） 如果gcms是进程在服务，可以先关闭掉进程，直接通过web服务器提供服务试一试！
参考手册：
Gcms服务手册。
iPaaS集成开发环境使用手册。
原理概述：
数据库出错，所以依赖数据库的动态程序，基本都会出问题；而数据库错误千奇百怪，但一般都有直接提示和快速解决方法。
iLogic每开发一个项目，我们对应后台一个新的用户和用户空间，创建项目时所用的英文用户名和密码，就是后台进入数据库所用的用户名密码，比如联通项目
|
|
辽宁联通功能管理 |
liaoning_manager |
publish |
liaoning_manager |
在后台我们可以用sqlplus liaoning_manager/liaoning_manager@publish进入该项目所属的数据库空间，所有生成的模板，组件的字段全都在这里可供排查，但由于该数据表时系统自动生成，建议只观察数据库记录，不要擅自改动数据表的结构。
典型情况：
数据库自身的错误返回；
数据库设计没有按预期模组进行；
数据库里根本没有数据！
调试方法：
（1） 确保iLogic对应模板的文档管理可以完整的进行增删改以及静态合成，否则就是模组没有正常设计；
（2） 根据数据库报错，一般是英文，复制它进入baidu或google，后者更好，查询就能发现大致的错误原因，进一步连接数据库直接确认原因；
（3） 进入数据库，直接查询数据表格，了解其基本情况，看是否跟模组设计基本一致！对于模组中的查询，你可以直接用字段真实名替代原组件名，直接执行查询看是否正确，否则为数据库自身使用错误！
参考手册：
iLogic数据库结构；
各种网上的数据库支持。
原理概述：
iLogic平台本身如果有bug，就会在所有人、所有机器甚至所有相似服务器上出现同样问题。
典型情况：
升级更新带来的问题比较常见。
调试方法：
（1） 确保至少三个人三个环境三个项目下出现同样相似的问题，从而彻底排除上述6种错误可能；
（2） 如果基本出现，但少数服务器可以，基本可估计是程序版本问题，请执行单个升级或云升级；
（3） 向iLogic技术支持报告该bug和可检测重复出现的方法，一定要描述多个地方可检测重复出现以及出现的操作步骤，这一样才能更快反应；
参考手册：
iLogic云升级手册和iLogic手动升级手册。
|
多级错误 |
|
多层次调试诊断方法：功能原型、二分法、断点 |
|
调试步骤：判断问题归属级别、在相应级别解决问题 |
|
调试基础：补充相关知识结构 |