需要架构指导？

Question

我们即将为报告团队自动化流程数量。 （报告类似于每日报告，每周报告，月报等。）

大多数情况下，这个过程就像从oracle中提取一些数据，然后填充它们 特别是excel模板文件。

每个报告都是如此，因此它们的模板彼此不同。 除了excel文件操作之外，这些背后几乎没有任何业务逻辑。

客户需要一个集成工具，并将所有自动化流程放置为 菜单/子菜单。

现在大致有大约30个流程等待自动化。 我们预计下一季度会有更多新报道。

在建筑设计方面，我无处可靠。 我一直在维护两到三个系统（它们已经超过4年了。） 对于这个狡猾的客户。上面提到的工具的可能性很可能会再持续3年。

从我过去的经历来看，我已经经历了向变通人员提出改变请求的痛苦。未记录的代码库导致系统崩溃，最终导致我自己。

所以我的主要和最关心的是维护。

当我搜索这些时，我遇到了这个链接， Smart Clients Using CAB and SCSF 上述链接是否符合我的要求？

此外，我是否应该在单个项目下将每个自动化流程放在单独的表单中， 或者将它们放在单一解决方案的单独项目中。

如果错过了任何其他重要信息，请纠正我。

THX。

Answer 1

为什么不用适当的报告解决方案替换各种Excel模板？使用体面的报告产品有以下好处：

• 每个人都可以访问相同的报告
• 您可以使用角色来阻止人们看到某些报告
• 用户每次运行时都可以更改报告的参数，也可以使用您为其设置的默认值
• 报告可以高度自动化，可以在某些时间表上自动运行（例如每周一早上9点，或者周末处理后的每个周日晚上）
• 报告可以多种格式提供
• 报告工具可以使用数据库中的存储过程，那些存储的过程可以封装业务逻辑

我个人主张使用Sql Server Reporting Services（2008版，尽量避免使用2005），尽管还有其他产品。 SSRS可以与Oracle数据库通信，可以免费获取和使用。

您还对“流程”做了模糊的引用。我读这个的方式，你有一些代码在某个地方运行，将数据从数据库中拉出来，稍微按摩它，并将其放入某个临时区域 - 也许Excel电子表格是暂存区域，并且进一步的报告来自该阶段数据。如果我的解释是正确的，那么上述报告产品（可能还有许多其他产品）无需这样做。

Answer 2

多年前我们建立了类似的系统。该系统由一个主进程和一系列实现插件体系结构的Excel报告生成器组成。每个报告都有自己的报告生成器，可以按照自己的时间表生成，非常类似于quartz和quartz.net处理调度的方式（但这是在创建它们之前很多年）。插件架构是系统的关键，因为可以动态创建和删除新的报告生成器。

主要流程负责启动/监控生成器，监听从生成器触发的事件以及分发所有报告。分布主要包括FTP到文件服务器，可以从网站查看和保存报告。但我们也有一些通过电子邮件发送到分发列表的报告。

存储所有报告数据的主数据库还存储了所有系统元数据，这些数据通知主要过程和生成器要执行的工作细节。

在我们的系统中，所有报告都按顺序运行，主要是由于当时的Excel限制。假设Excel现在能够自行运行，那么没有理由不能将新系统设计为以并行方式运行。