nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Backlog conversion - alf_data/contentstore/2011

dhartford

Hey all,
I'm doing a backlog conversion from a different content management solution into Alfresco.

The prior solution you could 'silo', or protect, the files after a period of time for example by year - so you can have those be read-only attributes, burned to DVD, and basically put it in a no-change state.

Evaluating Alfresco it seems you can do something similar as the alf_data seems to nicely by default break things up by year – but this seems only during creation of the images. The current/on-going injection process is using CMIS, however for the backlog conversion open to other options (assume the originating data is in whatever would make it easier - XML attributes & images, RDBMS and images, whatever…).

Is there some way I can backlog convert this old data on a yearly basis into similar alf_data/contentstore/2000, 2001, 2002, etc instead of having all the backlog content get thrown into 2011?

-D

Find more posts tagged with

Comments

mrogers

The content is read only. You can back it up to DVD in the same way.

dhartford

The question is, how do I inject in such a way so that 10 years of backlog data isn't *all* in contentstore/2011 (since /contentstore/2011 is based on create date).

mrogers

It will require some custom code, but you can set the URL of a new content item to whatever you want. So you could "backdate" content items.

It will be fairly low down in the content service, but I'm fairly sure there's already an API.

dhartford

thanks for the update - I was hoping it wouldn't be that far down in the layers, but knowing is better than not knowing.

Thanks for your feedback!

update: reviewing http://code.google.com/p/alfresco-bulk-filesystem-import/ to see if this will work (target system is 3.4.d CE).

-D

dhartford

Updates for anyone who may search for similar information, or if someone else can help correct any information below:

JCR approach for export/import:
*discussed and wiki'd, but no examples and several attempts do not appeared to have been successful.
http://wiki.alfresco.com/wiki/Export_and_Import
http://forums.alfresco.com/en/viewtopic.php?f=28&t=20599
http://forums.alfresco.com/en/viewtopic.php?t=2247

JCR approach would probably be the most desirable, and would make it easier for backlog conversion from one system to another system, but Alfresco doesn't appear to have many examples or successes.

ACP approach - version specific, not recommended for archival
*Not recommended if going between different versions of Alfresco. Alfresco-only export/import. Easy to accomplish through UI.
http://wiki.alfresco.com/wiki/ACP
http://wiki.alfresco.com/wiki/Export_and_Import

UPDATE: you can leave the below empty/no attribute and ACP imports the file fine.

view:childName="cm:13061754729372" (number unique) 
<sys:node-dbid>724</sys:node-dbid> (number unique) 
<sys:node-uuid>7f328602-fbf6-4ccb-b9e3-80839a39b6d8</sys:node-uuid> (number unique) 
‍‍‍‍‍

Note: The ACP approach requires you to load the entire ACP file directly into the repository in order to run the import, so make sure you have sufficient diskspace (double) for this kind of approach. Also note that even with create/modified date changes, it will still store into the contentstore for the current year and not based on any attributes in the file (so your entire backlog for example would go into contentstore/2011).

This approach under the covers is asingle large XML file for the attributes that has references to the images within the ACP file.

Bulk Filesystem Import - http://code.google.com/p/alfresco-bulk-filesystem-import/

*A good attempt to help deal with import/backlog conversion issues, however some problems with building (dependency issues from unavailable maven repository), and version conflicts (current 0.11 does not work with alfresco 3.4.d, only 3.3). Custom approach, but simple binary.ext followed with a java-property style binary.ext.properties file beside the binary file.

mrogers

I think the bulk import approach will be the way to go. That will be the easiest place to change how the content is stored in the repo according to your requirements.