Alfresco中文档的生命周期

  • A+
所属分类:使用集成

我想大家都已经知道生命周期是什么。我们出生,生活,死亡……事实上,对于Aflresco Nodes来说,这是完全一样的!好吧,至少从最终用户的角度来看。但是,这背后究竟是怎么回事?这就是我将在这篇文章中尝试解释的内容。

首先,什么是Alfresco节点?对于大多数人来说,Node只是存储在Alfresco中的文档,但实际上不仅仅如此:Alfresco中的所有内容都是一个Node!节点具有定义其属性的类型,并且还具有与其他节点的某些关联。这是一个非常简短的描述,但是我们不需要了解节点到底是什么来了解生命周期过程。因此,如上所述,Alfresco节点具有自己的生命周期,但它仅比三个简单步骤复杂一点。

请注意,在这篇文章中,我将使用$ ALF_HOME作为alfresco安装位置的引用(例如/opt/alfresco-4.2.c),并使用$ ALF_DATA作为alf_data位置的引用。默认情况下,alf_data文件夹为$ ALF_HOME / alf_data /。

一、创建

在这篇文章中,我将使用一个文档作为Alfresco节点来轻松理解该过程。因此,此生命周期从创建一个名为“ Test_Lifecycle.docx”的新文档开始,其创建日期如下:2015年2月1日,16:45。

在Alfresco中创建文档时,将完成三件事:

文件系统:此文件的内容存储在Alfresco“内容存储”中。默认情况下,内容存储在$ ALF_DATA / contentstore下。该文件实际上放置在此文件夹下的某个位置,具体取决于创建时间,并且为此文件指定了ID。对于我们的文件,它将是:$ ALF_DATA / contentstore / 2015/2/1/16/45 / 408a6980-237e-4315-88cd-6955053787c3.bin。
数据库:此文件的数据存储在Alfresco数据库中。实际上,在数据库中,主要使用其NodeRef或NodeID来引用此文档。我们可以在Alfresco Web界面的文档详细信息页面(文档的网络预览)上看到此NodeRef:http:// HOSTNAME:PORT / share / share / page / document-details?nodeRef = workspace:// SpacesStore / 09a8bd9f -0246-47a8-9701-29436c7d29a6。请注意,NodeRef包含一个UUID,但与Content Store一侧的ID不同。此外,数据库中还有一个属性,该属性将NodeRef链接到Alfresco的Content Store的ID,以便能够检索内容文件。
索引:在搜索引擎中为此文件创建了一个索引(对于Alfresco的旧版本可以是Lucene,对于较新的版本可以是Solr)。该索引在“工作区”存储区中。

二、更新,审阅,批准,发布…

创建文档后,他的生活就真正开始了。您可以手动或通过不同的过程自动更新/查看/批准/发布它。所有这些动作都是文档有效期的一部分。从管理的角度来看,这里没有太多要说的。

三、删除–用户级别

当不再需要文档时,无论出于何种原因,具有足够权限的用户都可以将其删除。对于我们的示例,假设用户使用2015年2月20日15:30(创建后19天)的Alfresco共享Web界面删除了文件“ Test_Lifecycle.docx”。使用Web Interface或Web Services删除文档时,将调用“ nodeService.deleteNode”方法。那么我们的“三件事”发生了什么?

FS:内容存储库上没有任何更改。文件内容仍然在这里。
DB:在DB端,NodeRef从工作空间:// SpacesStore / 09a8bd9f-0246-47a8-9701-29436c7d29a6更改为archive:// SpacesStore / 09a8bd9f-0246-47a8-9701-29436c7d29a6(“ store_id”字段已更改为“ alf_node”表)。
索引:与搜索索引相同:索引从“工作区”存储区移至“档案”存储区。
实际上,当用户从Alfresco的Web界面删除文档时,该文档只是移至“全局垃圾桶”中。默认情况下,所有用户都可以在Alfresco Explorer中访问此全局垃圾箱,以恢复他们可能误删除的文档。当然,他们看不到所有文档,而只能看到与它们相关的文档。在Alfresco Share上,此全局垃圾桶的访问权限在share-config.xml文件中配置,默认情况下,在大多数版本中,只有管理员可以访问它。

避免此全局垃圾箱的唯一方法是,通过对文档应用“ cm:temporary”方面,以编程方式删除文档,然后在其上调用“ nodeService.deleteNode”。这样,该文档将从UI中删除,而不会放入全局垃圾箱中。

四、删除–管理级别

我在这里所说的“管理级别”是默认情况下发生的第二级删除。此级别是从全局垃圾箱中删除文档。如果文档仍在全局垃圾箱中,则管理员(或用户,如果您使用的是Alfresco Explorer)仍可以还原文档。如果文档是“未删除”的,则它将返回之前的精确位置,当然,该文档的元数据和索引也将从“存档”存储区移至“工作区”存储区,以恢复活跃状态。

2015年4月1日上午8:05(在用户级别删除后的40天),管理员决定从全局垃圾箱中删除“ Test_Lifecycle.docx”。这可以手动或以编程方式完成。此外,还有一些现有的加载项,可以将其配置为自动删除XX天之前的垃圾箱中的元素。这次,称为“ NodeArchiveService.purgeArchiveNode”方法(在某些较旧的Alfresco版本中为archiveService.purge)。那么这次我们的“三件事”发生了什么?

FS:内容存储库上仍然没有任何更改。文件内容仍然在这里。
DB:在DB端,文档仍然存在,但是某些引用/字段(不是全部)已删除。当仅在“ alf_node”表上清空某些字段时,“ alf_content_data”表上的所有引用都将被删除。对于Alfresco 4.0及更低版本,表“ alf_node”上的“ node_deleted”字段从0更改为1。在较新版本的Alfresco上,“ node_deleted”已不存在,但节点的QNAME(字段“ type_qname_id” )“ alf_node”表上的)从51(“内容”)更改为140(“已删除”)。因此,该节点现在已从全局垃圾箱中删除,而Alfresco知道该节点现在可以安全地删除了,但是现在不能这样做……一旦设置了“ node_deleted”或“ type_qname_id”,则“ alf_content_url”上的“ orphan_time”字段该文档的表也从NULL更改为当前的unix时间戳(+ gmt偏移量)。
索引:此节点的搜索索引已删除。
如您所见,文件系统和数据库中仍有一些剩余元素。这就是为什么我们生命周期中的最后一步……

五、删除–更进一步

如您所见,文档“ Test_Lifecycle.docx”现在被视为“孤立”节点。默认情况下,在Alfresco上,所有孤立节点的保护期为14天。这意味着在此期间,孤立的节点将完全不会被触摸。当然,可以在Alfresco配置文件上轻松更改此值。那么14天后会发生什么呢?实际上,实际上每天凌晨4点(同样,默认情况下可以更改...),一个计划的作业(“ contentStoreCleaner”)会扫描Alfresco中是否有14天以上的孤立节点。因此,在2015年4月15日04:00,计划的作业开始运行,它的作用如下:

FS:内容文件从$ ALF_DATA / contentstore /移至$ ALF_DATA / contentstore.deleted /
DB:在DB端,文档仍在此处,但是“ alf_content_url”表(此表包含orphan_time并引用了FS位置)上与此文档相关的行已删除。
索引:无所事事,搜索索引已被删除。
您可以通过在alfresco-global.properties配置文件中设置“ system.content.eagerOrphanCleanup = true”来避免将文档放在“ contentstore.deleted”文件夹中的步骤。如果这样做,则14天后,文件系统上的文档不会移动,而是会被删除。

六、删除–最后!

如前所述,在Alfresco数据库上(尤其是在“ alf_node”表上)仍然有一些对“ Test_Lifecycle.docx”文档的引用。另一个计划的作业,nodeServiceCleanup每天在21:00运行,以清理与已删除30天以上的节点(孤立节点)有关的所有内容。因此,结果如下:

FS:内容文件仍位于$ ALF_DATA / contentstore.deleted /文件夹中
DB:DB终于干净了!
索引:无所事事,搜索索引已被删除。

七、其他

这么多步骤,不是吗!如前所述,剩下要做的就是从$ ALF_DATA / contentstore.deleted /文件夹中删除内容文件。您可能认为在XX天后还有一项工作可以为您完成该任务,但实际情况并非如此,Alfresco中没有任何东西可以从该位置删除内容文件。结果,如果您要清理文件系统,则必须自己完成。

例如,在Unix上,您可以简单地创建一个crontab条目:

50 23 * * * $ALF_HOME/scripts/cleanContentStoreDeleted.sh

然后创建此脚本。以下是可以解决问题的内容的示例,但是您可以在脚本中放入想要/需要的内容,以根据需要删除内容或创建备份:

#!/bin/bash

CS_DELETED=$ALF_DATA/contentstore.deleted/

# Remove all files from contentstore.deleted older than 30 days
find $CS_DELETED -type f -mtime +30 | xargs rm 2> /dev/null
# Remove all empty folders from contentstore.deleted older than 60 days
find $CS_DELETED -type d -mtime +60 -empty | xargs rm -r 2> /dev/null

请注意,您应该确保文件夹“ $ ALF_DATA / contentstore.deleted”存在。当我这样说时,我的意思是您必须绝对确定它存在。也请不要删除“ contentstore”文件夹下的任何内容,也不要删除“ contentstore.deleted”文件夹本身!

您可能想知道为什么清理垃圾箱时不能自动清理数据库,以及为什么文件内容也保留14天……所以我可以向您保证,原因有很多,主要原因是出于备份/还原性能方面的考虑。我将不作详细解释,但是基本上,由于默认情况下14天都不会触摸文件内容,因此这意味着您最多可以还原14天的数据库,而数据库仍将与文件系统保持一致,而无需进行任何操作。恢复FS!当然,如果您这样做,您将丢失最近14天上传/更改的文档,因为您的数据库在14天之前不知道这些文件。但是,您仅可以使用增量备份来备份/还原最近14天创建的内容文件。

例如:今天(2015年5月5日),我想备份FS(仅过去14天),那么我将必须备份$ ALF_DATA / contentstore / 2015/5中的所有文件夹,并且我还必须备份所有$ ALF_DATA / contentstore / 2015/4内的文件夹,其文件夹名称大于或等于30(4月的天数)+ 5(5月的天数)– 14 =21。
我希望此帖子足够清楚,因为它的确可以很难理解有关Alfresco Node生命周期的所有信息并正确处理。

发表评论

您必须才能发表评论!