有没有人使用过或研究过 Jitterbit 以及 BizTalk?如果是这样,每种方法的优缺点是什么,您选择哪一种作为最终解决方案?
具体来说,我正在寻找 SAP 集成,但任何输入将不胜感激。
和 Rob 一样,在阅读您的问题之前我还没有听说过 JitterBit(谢谢!),然而,在过去的 9 年里,我几乎一直在使用 BizTalk;出于这个原因,我不确定我是否应该做出回应,但正如 Rob 所做的那样,其他人都没有,我认为它值几美分......
从我所做的少量阅读来看,在我看来,JitterBit 除了是一个有优点和缺点的开源之外,还试图通过提供一个相对简单的解决方案来降低进入门槛,并承诺快速开发和拖拽-n-drop 方法“没有自定义代码”。
我会从表面上接受他们的承诺,因为我对此一无所知,尽管我有疑问,所以让我们假设使用 JitterBit 进行开发非常容易,我可以明确说明一件事 - 使用 BizTalk 进行开发不是。
但是,这有点,但在我看来,使用 BizTalk 进行开发有些困难,不是因为微软在这方面做得不好,相反 - 使用 BizTalk 开发有些困难,因为微软希望创建一个可以实际允许企业很好地解决了他们的 BPM 和集成需求,而且根据我的经验,这些问题几乎从来都不是简单的,因此微软构建了一个具有许多功能、非常强大且非常灵活的服务器,但代价是复杂性。
因此,虽然任何有经验的技术销售人员都可以为您演示一个非常简单的集成场景,并且使用大量拖放和配置在几分钟内开发,即使在 BizTalk 中也是如此,但这是一个现实的企业吗?水平解决方案?这是一个真实的场景吗?根据我的经验,答案几乎完全是否定的;这些问题往往很复杂,需要更强大的解决方案。
所以,我想底线是——如果你正在寻找一个一次性的解决方案,并且开源是你们一起工作的东西——JitterBit 绝对值得一看,看看它是否能够提供帮助,并且确实,学习曲线短(关注维护、监控、故障排除、实例管理等很重要)
但是,如果您相信(通常情况下)您的解决方案将发展成为您组织中的 BPM/集成平台,并且您需要更强大的东西 - 我会把钱放在 BizTalk 上,使其成为更好的候选人。
从旧的 SAP DCOM 连接器开始,我已经与 SAP 进行了相当多的集成。最近,我参与了在企业服务总线模式中服务的集成平台的选择。
我们制作了 Web 服务示例以在多个平台上连接到 SAP,包括 BizTalk、Mule、Netweaver、Webmethods 和 Tibco。尽管 BizTalk 和 Netweaver 都获得了很高的分数,但 Webmethods 在许可和能力方面胜出。
Jitterbit 不是评估的一部分——事实上,我必须查一下以确保我理解了你的问题。
如果您的目标只是能够调用 RFC,那么 .NET SAP 连接器可以很好地工作。
如果您的目标是公开 Web 服务以包装 SAP 中的流程,那么 BizTalk 很好,但我建议您查看您的组织是否已经获得了 netweaver 许可,因为有许多无需编码即可直接从 SAP 获得的 Web 服务。
我的建议是暂时避免在企业中使用 Jitterbug 和 Mule - 除非开源在您的工作场所实际上很受欢迎。Netweaver 和 BizTalk 是非常强大、完善的产品。
如果您正在寻找可以轻松发货的东西,那么 Jitterbug 可能更有意义。虽然通常我建议您将其定义为 Web 服务调用,并从您的客户技术堆栈中寻找最合适的集成技术。
您希望实现的目标的更多背景信息将有助于获得更准确的答案。
迈克尔,
我们在我们的组织中使用 Jitterbit,我们在各种项目中都非常成功。我们的 SAP 项目使用 XI,而 Jitterbit 极大地简化了将 Web 服务接口与其支持的各种协议集成的能力。
除了优惠的价格(我们现在订阅 Jitterbit 以获得支持)外,我们还从支持服务中实现了巨大的价值。如果我们在实施过程中有任何问题,他们似乎提供了包含在支持成本中的所有主题专业知识,因此我们完全可以自给自足。
我们公司还有很多其他的集成解决方案,包括VB和Java程序;这是一团糟,但我们不相信任何一个平台都能满足我们所有不同部门的需求。多年来,我们一直在使用开源,特别是 Linux 和 Apache,尽管 IBM 和微软在这里也很流行。
我们选择了 Jitterbit,因为它支持集成任何现代系统所需的协议,并且 SOA / Web 服务是我们明确的方向,Jitterbit 非常适合我们的需求。
鉴于 Jitterbit 是开源的,我鼓励您下载并试用。
我会简单地说,我一直在使用 biztalk,并且是帮助验证 2006 年培训课程的人之一。Biztalk 是目前可用的业务流程的最佳服务器应用程序之一。您还必须考虑到与其他产品相比,价格点低得离谱。