临时“备份”功能和解决方案部署期间的 SharePoint 内容
我需要决定一种在 SharePoint 网站中存储内容子集的方法,以便当我作为功能激活的一部分删除并重新创建某些列表时,我可以将所有这些内容重新插入到其应有的位置。我自己有一个想法,但我不知道这是否是唯一的方法,更重要的是,是否是正确的方法。
我的客户让我创建一个 SharePoint 系统,以便他们与他们的客户进行通信。业务流程可能有 5 个阶段(也许更多,我什至不知道,因为他们没有告诉我一切),而我在过去几个月编写的当前系统可能有 2 个阶段。这满足了我们在下周星期一之前完成这些系统的最后期限……但那时我的客户正计划从那时起使该网站上线。
实际上,他们与客户的工作将与我为他们所做的工作并行进行。当我在单独的测试服务器上完成自己的工作时,我会将流程的每个后续阶段推送到实时服务器上。我可以在非工作时间(例如周末)安排停机时间来执行这些推送。跟上步伐,使我的开发速度快于实际的业务流程是我自己的问题,也是题外话……所以让我们回到我在本文开头提到的问题。
在此系统中,我们有一组功能,这些功能将在激活时为其关联的内容类型和字段类型创建列表,并在功能停用时删除这些列表。大多数更新不需要停用和重新激活这些功能,例如工作流程更改、自定义操作、自定义表单等。但有些部分确实需要这样做。在我的测试服务器上,删除列表对我来说是可以的,但是一旦网站上线并且有了真实的通信数据,这样做是绝对不可接受的。因此,当我需要实现新的功能更改时,我需要能够将当前存在的数据存储在多个列表中、停用该功能、重新激活该功能以及恢复所有这些数据。
也许我因自己实现的功能系统而自食其果。不幸的是,后来需要制作几个这样的“项目站点”,这意味着我必须在编写大量代码时牢记“可以重复部署”的概念。
我当前的计划是遍历列表和库,这些列表和库将受到要重置的特定功能的影响。文件及其所有版本将保存在服务器上的目录中。然后,将使用一组文本文件来存储项目的所有重要字段值。这包括需要维护的大量跨列表引用查找,但这很简单。然后,我停用该功能,部署新解决方案,然后重新激活该功能。我们按照版本指定的顺序上传所有文件,并使用这些版本的存储字段更新它们,以便保留版本结构。当每个文件第一次上传时,都会选出新的 ID,并更新其余文件中的所有相关查找(当然,以某种方式,我确保以后不会使用不正确的值重新更新它) )。之后,我们按照最有利于保持关系数据正确的顺序遍历所有其余项目。这大致概括了我目前的计划。对我来说,系统中没有长期运行的工作流程会受到此影响,因此当我执行此操作时,我无需担心确保没有任何内容“仍在运行”。
我真的不知道这种方法的所有缺点......我可以想象它们相当沉重。但我不确定我还有什么其他选择,而且我的搜索也没有找到任何结果。有谁能想出更好的主意吗?或者有人会告诉我我真的别无选择?提前致谢!
I need to decide on a method for storing a subset of the content in a SharePoint site, so that when I delete and recreate certain lists as part of a feature activation, I can re-insert all of this content back where it should belong. I have an idea myself, but I don't know if it's the only method and more importantly, the right method.
My client has me creating a SharePoint system for them to communicate with their clients. The business process has maybe 5 stages in it (maybe it's more, I don't even know because they don't tell me everything), and the current system I've written over the past months is maybe 2 stages through. This meets our deadline of completing those systems by Monday next week... but at that point my client is planning on making the site live from that point.
In effect, their work with their clients will be running parallel with my work for them. As I complete my own work on a separate test server, I'll push each following stage of the process onto the live server. Scheduled downtimes during non-business times (like a weekend) will be available for me to perform these pushes. Keeping pace so that my development is faster than the actual business process is my own problem and off-topic... so let's get back to the problem I stated at the start of this post.
In this system, we have sets of features which will create lists for their associated content types and field types when activated, and delete these lists when the feature is deactivated. Most updates don't need to deactivate and reactivate these features, such as workflow changes, custom actions, custom forms, and similar ilk. But there are some parts which do require this. On my test server, it's okay for me to obliterate lists, but once the site is live and there's real correspondence data, it's absolutely unacceptable to do this. So when I need to implement a new change in functionality, I need to be able to store the currently present data in several lists, deactivate the feature, reactivate the feature, and restore all of this data.
Perhaps I have hoist myself by my own petard with the feature system I implemented. Unfortunately, the necessity to later on make several of these "project sites" meant I had to do a lot of my code with the concept of "Can be deployed repeatedly" in mind.
My current plan is to run through lists and libraries which will be affected by the particular feature that is to be reset. Files and all of their versions will be saved in a directory on the server. Then, a set of text files will be used to store all of the important field values for the items. This includes a lot of cross-list reference lookups that will need to be maintained, but that's simple enough. Then, I deactivate the feature, deploy the new solution, and reactivate the feature. We upload all of the files in the order specified by their versions and update them with the stored fields for those versions, so that we retain the version structure. As each one is first uploaded, the new ID is picked out, and all relevant lookups in the rest of the files are updated (in some manner that I make sure I don't re-update it later with an incorrect value, of course). After that, we run through all the rest of the items in the order most conducive to keeping the relational data correct. This roughly summarizes what my current plan is. To my advantage, there are no long running workflows in the system that will be affected by this, so there's nothing I will have to worry about making sure nothing is "still running" when I do this stuff.
I don't really know all the cons of this approach... I can imagine they're quite hefty. But I'm unsure what other choices I even have, and my searches haven't turned up anything. Is there anyone who can think of a better idea? Or will anyone just tell me that I really have no other choice? Thanks in advance!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
好吧,祝你好运......如果你真的需要删除东西,我认为你现在没有其他选择。然而,如果你能以某种方式找到一种不必这样做的方法......
尽管如此,我能想到的很少有事情 - 阅读所有内容可能需要几个小时,如果有人为某个项目添加书签或将链接发送给其他人,它就不会'更新后无法工作,必须对架构进行更改将是一件痛苦的事情。正如 SharePoint 的通常情况一样,当您到达那里时,肯定会潜伏在表面下一些问题来困扰您。
Well, good luck... I don't think you have other choices at this point, if you really need to delete stuff. However, if you could somehow come with a way of not having to do that...
Nevertheless, few things I can think of - readding everything could take hours, if someone bookmarks an item or sends the link to someone else, it won't work after an update, having to do changes in the schema will be a pain. And as is usually the case with SharePoint, there'll surely be some problems lurking just under the surface to bite you when you get there.