与500多个应用程序集成
我们的客户使用500多个应用程序，我们希望将这些应用程序与我们的产品集成 什么是最好的方法来做到这一点？ 这些应用程序是时间注册应用程序，其中大部分是共同的，他们可以出口到CSV或类似的，其中一些实际上是家庭酿造的Excel表格，时间注册。
到目前为止，最好的想法是创build我们自己的excel表单，它可以用来与所有这些应用程序集成。 这个集成可以是包含像='[c：\ export.csv] rawdata'的单元格forms！$ A $ 3其中export.csv是从时间注册应用程序导出的csv文件。 你能看到一个更好的方法来整合所有这些应用程序吗？ 应该提到，几乎所有的客户都有Microsoft Office。
编辑：从Pontus Gagge的优秀问题的答案：
不同应用程序中的数据有多相似？ 我认为自从他们申请注册申请之后，他们会有一些相似之处，但是我认为有些人会注册一个月总共工作了多长时间，而另外一些人则每天都会有所规定。 如果selectExcel，我相信很多差异可以用基本公式来解决。
数据的质量是多less？ 数据的质量可能有所不同，所以必须进行基本的validation，一个好的方法是让客户透明，我们的应用程序如何理解他们的input，所以他们负责。
你在谈论多大数据量？ 将会有关于多达50名员工的工作时间的信息。
整合是单向的吗？ 是
信息传输的频率应该是多less？ 每月一次（当他们需要支付工资时）。
应用程序本身多长时间更换一次，以及您的产品多久更换一次？ 如果他们的申请是自制的Excel表格，那么我认为它会每年更换一次（例如由于错误的人）。 如果这是一个标准的适当的时间注册申请，那么我不认为他们每五年更新一次，因为这是一个非常稳定的概念。
整合是完全自动的还是最终用户可以触发数据传输？ 他们肯定可以触发数据传输。 用户经常致力于这个过程，所以他们可以接受培训，这意味着他们可以通过30次鼠标点击来整合每个月。
客户是否有人监控整合？ 由于我们有很多客户，他们中的许多人应该能够自己进行整合。 我们将尽可能通过电话帮助他们。 我们不能，虽然我们自己进行整合，因为我们会因使用者的错误而导致任何错误。
“融合意大利面条”对你来说意味着什么…？ 我正在寻找来自最好的厨师的想法，做出很好的一大部分。
你需要想出一个通用的数据格式，以及将单个数据格式转换成通用格式的方法。 真的没有办法解决这个问题 – 你提出的任何解决scheme都必须以某种方式做到这一点。 这是你所做的重要的复杂性。
更大的问题是源数据中的差异，就如何存储date，缺less列等方面而言。对CSV进行通用转换以移动列是比较容易的。
我也看看CSV，然后使用OLEDB连接对CSV文件进行导入。
如果你试图做一些可以与宇宙中的任何数据结构接口的东西（而且足够接近500），那么这将是一个维护的噩梦。 相反，我会从多个angular度来处理这个问题：
-
devise一个人类可以input这个数据的界面已经以适当的格式。 有了500多个客户端，我可以把这个小巧的，function强大的基于浏览器的网站制作成用户可以用来手动input这些信息。 这是倒退。 在这一天结束的时候，一个人可以将信息重新input到网站，并解决import问题。 理想情况下，每个人都会使用这个而不是自己的格式。 数据录入人员便宜。
-
与上面类似，但扩展了，我会开发一个标准的应用程序或标准化一个现成的应用程序，可以用来取代他们现有的格式。 这可能比＃1需要更多的时间。 目标只是将这些不同的数据模式一次性导入到应用程序中，并与其一起完成。
-
电子表格的好处是你可以在任何地方做任何事情。 电子表格的坏处是你可以在任何地方做任何事情。 使用CSV或电子表格，无法强制执行数据完整性，从而无法实现数据的一致性（这是主要目标）。 如果源数据已经在数据库中，那显然更简单。
我倾向于使用数据库格式，其中每个这些文件需要被转换，而不是电子表格（例如使用像Jet（MDB）的东西）。 如果你有非Windows用户，那么这将使它更难，你可能不得不使用电子表格。 问题是用户很容易改变他们的源码结构，打破他们的上传和哭泣给你。 如果给定的最终用户有一位常驻专家，他们可以find一种将数据导入到数据库格式的方法。 如果你是那个专家，那么我会根据具体情况编写一些能导入到数据库格式的东西。 XML是另一种select，但这可能需要比input/输出成数据库格式更多的编码。
应用程序的标准化（甚至是以数据库格式而不是电子表格的所有来源将会有所帮助），并且控制数据模式是最终的目标，而不是允许巨型格式。 除了标准化以外，没有什么好的答案。 否则，你必须为每一个汤姆 – 迪克 – 哈利格式编写一个转换器，并且当有人改变源格式时再一次编写一个转换器。
使用大量的数据源将每个数据源正确地映射到中间格式并非易事。 正则expression式对于有限的已知数据格式是很好的。 如果数据在没有上下文的情况下模糊不清（没有月份，date字段并且有数天的数据），Multipass可以提供帮助，还有助于打破数据录入错误。 但是，这个数据似乎与工资有关，需要一个很好的可靠的转移。
导入configuration技巧
让客户在应用程序中创build一组训练数据。 它应该有一个“预定义的唯一date”，每个后续的数据字段都有一个对应于应用程序中目标数据字段的数字。 在导入您的应用程序时，需要识别预定义的date，确定所需的唯一翻译，并显示/保存此“映射键”，并停止导入。 例如，如果您希望在第二栏中input“持续时间”，那么请让用户在相关字段中input2，可能是“出勤时间”。
在随后的运行中，使用映射定义键，导入变成一个相当简单的翻译过程。
条款说明
- “预定义的date” – 必须是历史的，例如你公司的创builddate，可能需要在PC时钟可设置的范围内。
- “映射键” – 可以是hex数字和nybble的string，以便于锻炼。input的代码可以扩展以表示所需的转换，即客户的应用程序在几天内持续了一段时间，应用程序在几个小时内就可以看到它。
与Windows程序接口（为了增加脆弱性，
- Ye Olde保存为CSV文件
- 打印到设置为文本文件/ pdf的操作系统打印机，然后从中清除数据
- 通过应用程序接口控件提取数据，通常是几个Windows程序的ActiveX，例如Matlab的Spreadsheet Link
- 读取本地文件格式xls格式，如Matlab的xlsread
- 添加一个额外的中间电子表格表，扩展了单元格引用ie ='[filename] rawdata'！$ A $ 3
看看JBoss的Teiid： http ://jboss.org/teiid
还要考虑使用SOA – 例如，如果您使用的是Java，请尝试使用JBoss SOA平台： http ://www.jboss.com/resources/soa/?intcmp= 1004
使用简单的XML格式。 非技术人员可以轻松理解简单的XML格式（甚至可以识别不正确的XML文档的基本问题）。
也许使用DTD（甚至更好的XML模式）来做非常基本的validation，然后用XSL样式表作为补充，以更好的错误报告进行更多的validation。 （一个XSL样式表只是简单地将XML转换成其他的东西，所以可以生成可读的错误信息。）
这种方法的优点是Web浏览器（如Internet Explorer）可以应用XSL样式表。 客户最多只需要花一天时间来增强他们的应用程序或编写excelmacros来以您指定的格式生成XML数据。
最近版本的Excel支持将电子表格数据转换为XML，甚至可以针对模式进行validation。
一旦数据通过了XSLvalidation检查，就validation了XML数据。
如果你有大量的数据和资金，你可以看看现有的数据pipe理和清理工具：
http://www-01.ibm.com/software/data/infosphere/datastage
http://www-01.ibm.com/software/data/infosphere/qualitystage
但即使如此，假设您拥有500多种数据格式，您也可能需要遵循kyoryu的build议。 问题不在你身边。 如果您无法控制其应用程序，则需要他们将其输出格式标准化。 CSV可能是最简单的。 你甚至可以给他们发送一个excel模板来帮助他们。