与500+应用集成

Question

我们的客户使用500+应用程序，我们希望将这些应用程序与我们的。做这件事的最好方法是什么？这些应用程序是时间注册申请，其中大多数是常见的是，他们可以导出到csv或类似的，其中一些实际上是自制的excel表格，其中的时间是登记。

到目前为止，最好的想法是创建我们自己的excel工作表，它可以用来集成所有这些应用程序。集成可以以单元格的形式进行，其中包含='c:\export.csvrawdata'!$A$3，其中export.csv是从时间注册应用程序导出的csv文件。您能看到一个更好的方法来集成所有这些应用程序吗？应该指出的是，几乎我们所有的客户都有Microsoft。

编辑:回答来自Pontus Gagge的优秀问题：

不同应用程序中的数据有多相似？我假设，由于他们的时间登记申请，他们将有一些相似之处，但我认为，有些人将登记的时间总共工作了整整一个月，而另一些将加速的每一天。如果选择Excel，我相信许多差异可以用基本公式解决。

数据的质量是什么？数据的质量可能会有所不同，因此必须进行基本的验证，一个很好的方法也是使其对客户透明，我们的应用程序如何理解他们的输入，因此他们是负责的。

你说的是多少数据？将有多达50名员工的工作时间的信息。

整合是单向的吗？是

信息应该以什么频率传送？每月一次(当他们需要支付工资时)。

应用程序本身多久改变一次，您的产品多久变化一次？如果他们的应用程序是一个自制的Excel表格，那么我假设它每年会更改一次(例如，某个人的错误)。如果这是一个标准的适当时间注册申请，那么我不相信更新的频率比每五年左右，因为这是一个非常稳定的概念。

集成应该是完全自动化的，还是您的最终用户可以触发数据传输？它们肯定能触发数据传输。用户通常专注于这个过程，因此他们可以接受培训，这意味着他们可以弥补鼠标点击，比如30次点击，以便每个月进行集成。

客户会有谁来监控整合吗？由于我们有许多客户，他们中的许多人应该能够自己进行集成。不过，我们可以通过电话向他们提供协助。我们不能，虽然我们自己承担集成，因为我们将负责任何错误由于用户的错误，等等。

“一体化意大利面”对你有什么意义吗.？我正在寻找最好的厨师的想法来烹饪一个很好的大部分。

Answer 1

您需要想出一种通用的数据格式，以及一种将单个数据格式转换为公共格式的方法。这是没有办法的--你想出的任何解决方案都必须以这样或那样的方式完成。这是你所做的事情的本质复杂性。

更大的问题实际上是源数据中的差异，比如日期的存储方式、缺少的列等等。对CSV进行通用的转换来移动列是相对容易的。

Answer 2

我还将查看CSV，然后对CSV文件使用OLEDB连接进行导入。

Answer 3

如果您试图制作一些可以与宇宙中的任何数据结构接口的东西(而且500非常接近)，那么它肯定是维护的噩梦。相反，我会从多个角度来处理这个问题：

1. 设计了一个接口，人类可以在其中以适当的格式输入这些数据。有了500+客户端，我会把它变成一个小型的、原始的、基于功能的基于浏览器的站点，用户可以用它来手动地输入这些信息。这是替罪羊。最终，人类可以将信息重新输入站点并解决导入问题。理想情况下，每个人都会使用这个格式而不是他们自己的格式。数据录入人很便宜。
2. 与上面类似，但经过扩展，我会开发一个标准的应用程序或对现成的应用程序进行标准化，这些应用程序可以用来替换现有的格式。这可能需要比#1更多的时间。目标是只一次将这些不同的数据模式导入应用程序，并对它们进行永久的处理。
3. 电子表格的好处是您可以在任何地方做任何事情。电子表格的坏处在于你可以在任何地方做任何事情。使用CSV或电子表格，根本没有办法在数据上强制执行数据完整性，从而实现一致性(这是主要目标)。如果源数据已经在数据库中，那么这显然更简单。

我倾向于使用需要转换的数据库格式，而不是电子表格(例如，使用Jet (MDB)之类的东西)。如果您有非Windows用户，那么这将使它更加困难，您可能不得不使用电子表格。问题是，用户很容易改变他们的源结构，破坏他们的上传，并向你哭诉。如果给定的最终用户有常驻专家，他们可以找到将数据导入该数据库格式的方法。如果你是那个专家，那么我会逐案地写一些能导入到数据库格式中的东西。XML将是另一种选择，但这可能比导入/导出到数据库格式需要更多的编码。

应用程序的标准化(甚至所有源都采用数据库格式而不是电子表格)和控制数据模式是最终目标，而不是允许大量格式。除了标准化之外，真的没有其他好的答案。否则，当有人更改源格式时，您必须为每个Tom-Dick-和-Harry格式编写一个转换器。