Edit: For things below to work, you do need to edit packaging.conf as xnormand stated above.
This seems to be what you said your tried, but since you were not very detailed:
If you use the tool UploadTest bundled with ACS4.1 distribution (it has to be 4.1 or above; 4.0's will not replace already existing resources), create the associated XML:
<?xml version="1.0" encoding="UTF-8"?> <package xmlns="http://ns.adobe.com/adept"> <action>replace</action> <resource>urn:uuid:00000000-0000-0000-0000-000000000000</resource> <metadata xmlns:dc="http://purl.org/dc/elements/1.1/"> <dc:title>XXXXXXX</dc:title> <dc:creator>XXXXXXX</dc:creator> <dc:publisher>XXXXXXX</dc:publisher> <dc:format>application/epub+zip</dc:format> </metadata> <dataPath>/home/myuser/epubs/filename.epub</dataPath> </package>
Note that, in the XML:
<resource>has to be exactly the same as the UUID of the book already in ACS that you intend to replace.
Then run the tool from the Terminal like this:
java -Xmx512M -jar /pathTo/UploadTest-1_2.jar http://domain.com/Package ~/epubs/ -datapath -xml -jpg -pass yourpassword
/pathTo/UploadTest-1_2.jarpoints to ACS 4.1 or above's UploadTest sample tool.
http://domain.com/Packageis the URL to your server's ACS's install of the Packaging service (depending on your server's install, port may have to be specified like
~/epubs/is your local path where the XML resides. Note that UploadTest will try to process all XML in that folder, not just the one you just created.
-datapathif you are packaging an epub residing not on your local machine, but on the server. Obviously requires the
dataPathin the XML.
yourpasswordis your password to ACS' Packaging service. Since you are running this on the shell, watch out for plaintext password leftovers in your command history. Some UNIX installs do not add lines to the command history if the command is preceded with a space (but YMMV).
You cannot only update metadata without resubmit you ebook.
When doing this, you must be sure that:
1- The action of your request is action="replace"
2- You resubmit the same exact ressource id in tag "<resource></resource>"
3- Path to your ebook source file "<dataPath>/Path/To/Source/File</dataPath>"
4- As mention before add "
com.adobe.adept.packaging.allowURLCollisionsOnReplace=true" in your packaging.conf and restart tomcat
Let me know if you need anything else.
OK but what happen to users who bought previous version of e-book and would like to download again?
Or, even worse, what about users who are in "process of fulfillment"?
Do ADE and others readers cope with such situations?
Is it safe from that point of view?
Please remember that in the simplest setup encrypted files are jsut stored in some server directory. Imagine, ADE is downloading that encrypted file from the server then unexpectedly this old file is overwritten by another one as result of replace action...
The fulfillment in the content server is associate with a "ressourceid". If you replace the ressource using the "replace" action in a package request you only replacing the data for that ressource and your NOT creating a new ressource.
So next time you try to redownload, ADE will contact YOUR content server to validate the existing liscense and will let you download to new version that you replace without contacting Adobe server.
Hope i'm clear. It not always easy to understand all the process.
I hope you are right
(But unfortuantely I have found same races in 4.0 - for instance two concurrent execution of package service often produce incorrect results if the same book is packaged)
So I am a little sceptical )
You can change the metadata that is stored in the ACS4 database by using the appropriate Admin web API (ManageResourceItem in this case). You will want to see the Tech Ref for the details.
This will not however change the metadata that is in the ePub - for this you will need to change the ePub and then repackage it.