本站于2023年9月4日。收到“大连君*****咨询有限公司”通知
说我们IIS7站长博客，有一篇博文用了他们的图片。
要求我们给他们一张图片6000元。要不然法院告我们
为避免不必要的麻烦，IIS7站长博客，全站内容图片下架、并积极应诉
博文内容全部不再显示，请需要相关资讯的站长朋友到必应搜索。谢谢！
另祝：版权碰瓷诈骗团伙，早日弃暗投明。
相关新闻：借版权之名、行诈骗之实，周某因犯诈骗罪被判处有期徒刑十一年六个月
叹！百花齐放的时代,渐行渐远!
推荐 IIS7批量FTP管理工具
IIS7批量FTP管理
IIS7批量FTP管理功能说明：
1、可批量导入，导出FTP信息
2、其他ftp工具有的功能，我们也有
3、特色功能：可以
定时上传下载
4、数据信息列表化、一眼就能知道那个是那个
5、批量连接 标签页式切换 方便快捷
6、7大连接模式 更多好的兼容
7、内嵌编辑器 有效解决普通txt记事本乱码
8、锁屏功能 当程序有规定时间内没人操作，则自动锁程序。输入密码才可以正常操作
本产品适用于：懒得记录FTP信息和有批量定时备份，上传下载的运维或站长。
图：
IIS7批量FTP管理
我们希望能在数据出错时，将错误的数据放到队列的末尾，这样能保证数据能一直处理下去，而不会发生堵塞？
以CRM inbound processing为例，数据从ERP到了CRM后，
Middleware framework会call application 自己的逻辑，如果application inbound里发生了异常，而没有在application里处理，则该异常就抛到了framework layer，导致队列里剩下的item没机会得到处理，BDOC亮红灯。
我当时的思路就是，把standard 不支持，但是客户又确实用到的scenario抽象成一个exception，当application检测到这种情况后，application 抛exception，然后在最外面，就是application的入口处catch住该exception，输入error message，然后继续队列里下一个item的处理。
但是这个思路是将这个issue当做标准产品的一个bug处理的，即需要修改application的代码。如果partner consultant想通过不改标准代码，仅仅写一些BAdI是没法完成的。
另外如果把adapter对应的block size改成1的话，即每个队列的size就为1，这样比如有N个material从ERP到CRM，则会在CRM生成N个队列，每个队列size为1，这样就使得每个队列里唯一的material的inbound处理独立开来，但是inbound 处理不再是mass handling的，我们没有测试过block size =1 对性能影响究竟有多大。
cs
