Leave feedback
  • Question

    Deployment failure due to Document Type revision incosistency

Enter a new topic
  • Philip Skogsberg Philip Skogsberg
    0 likes 1459 views

    Hi,

    When trying to deploy to our test environment (running on linux) Control Center throws an error message stating that there is a revision mismatch of the document types. I am clueless as to where or when this revision diff was introduced (see DocTypeREvisionDeployFail.jpg screenshot for error message). In other words, the currently deployed export file is one revision ahead of the one I was trying to deploy. Directly after this I get an error message from the domain manager ("domainmanager error msg.jpg" screen shot) 
    I don't know how this revision difference has occurred as there shouldn't e any difference between the export files in regards to the document type revisions. The specific diff pertains to this line in document type xml: 

    <metadata name="Part.TrackerID" scope="BBC0626F-EE2C-47A9-BC02-D5CB4D15C438" type="xs:string" guid="0DB19BF7-9474-4785-A3DB-841A49F145D9" archived="true" message="false" postprocess="true"/>

    in the deployed xml the vale message is equal to 'true' whereas the current one I want to deploy has this value set to 'false', as above. I don't understand how this has happened. 

    I have tried deleting the current Document Type definition via control center I then get an error about "integrity constraint violated" (see the DocTypeDeleteFailure.jpg screen shot). 

    It seems one solution to this is to manually go into the database or the use the Database Administration Tool to delete the document type or change the message variable, but this seems risky and we would be at risk of loosing all the current configurations in Streamstudio Composer, etc.

    Any suggestions or reading tips?

    Thanks

    Thursday 05 February, 2015
  • Tony RANNOU Tony RANNOU
    0 likes

    Hi Philip, are you several users to work on StreamServe ? we can explain this by 2 referentials sources with 2 developpers.

    Tony

    Thursday 05 February, 2015
  • Philip Skogsberg Philip Skogsberg
    0 likes

    I'm nor sure what you mean with 2 sources and 2 developers? 

    Anyway, we have solved the problem via a work around: As I mentioned previously the mismatch in the revisions was due to the message value in the document type being true in the deployed revision but false in the one belonging to the export file we were trying to deploy. Moreover, the Test environment's currently deployed export file had a document type in the global resource set that was marked as Revision 41, while the (most current) one we wanted to deploy was of revision 40. Again, I don't know how we managed to change that message value and I also don't know how the test environment's export file had a document type of a higher revision than the latest one we were working on in development (41 vs 40).

    Nevertheless, we decided to manually change the message variable value twice so that the document type now got updated to revision 42, one a head of the deployed version. Doing so made it possible to re-deploy all export files, but a "forced update" was required (probably because of the new revision?). 

    Monday 09 February, 2015
  • Martin Hale Martin Hale
    1 likes

    I think what Tony meant with his multiple developers reference was that its easy to get the versioning out of synch like this when more than one person is working on copies of a project. If one gets ahead on the versioning that could explain the cause of the problem.

    You've fixed the issue in the way most would recommend - make changes to get the current document type version to increase. If you ever get a similar issue with template versions for CompCtr then you can update your template version in StoryTeller under File>Processing Properties>Composition Centre.

    Monday 09 February, 2015
  • Philip Skogsberg Philip Skogsberg
    0 likes
    Martin Hale wrote

    I think what Tony meant with his multiple developers reference was that its easy to get the versioning out of synch like this when more than one person is working on copies of a project. If one gets ahead on the versioning that could explain the cause of the problem.

    You've fixed the issue in the way most would recommend - make changes to get the current document type version to increase. If you ever get a similar issue with template versions for CompCtr then you can update your template version in StoryTeller under File>Processing Properties>Composition Centre.

    Ah, right. I figured it was something like that. Thanks for the tip, but unfortunately we are not using StoreTeller yet, still working with PageOUT. Is there a similar way to update the template version in PageOUT?

    Tuesday 10 February, 2015
  • David Shih David Shih StreamServe Employee
    1 likes

    Side note to explain why you got the error message when trying to delete the DocType from Control Center: if you have DocBroker documents, CorrMan messages, or Strs queued Jobs still referencing the DocType, you cannot delete it or roll-back to a previous version.

    If you want to roll back to a prior version,

    1. Shut down all StreamServer instances in your app domain, just in case you decide to Drop Storages.

    2. Launch DBAT on your DocBrokerPlus Repository. Delete Expired jobs. Stubborn jobs may require that you cancel, or alter their ProcessingState, ProcessingStatus, or whatever. (When possible, I find it easier to use a larger hammer and just Drop Storages for all affected DocTypes.)

    3. Launch DBAT on your Runtime Repository. If you're using it for DocBrokerPlus, repeat above, but on this repository.

    4. In DBAT on your Runtime Repository, go to the Composition Center Messages. Expire/Delete/Cancel any lingering messages. (Or, if you can, and all StreamServer instances are shut down, go to each DocType and Drop Storage.)

    5. In DBAT on your Runtime Repository, go to the queued Jobs. Expire/Delete/Cancel everything.

    6. You should now be able to Delete the newer DocType versions.

    Tuesday 10 February, 2015
  • Martin Hale Martin Hale
    0 likes

    I don't think there's a template version option in PageOUT. PageOUT has only just been made available for use as a template for CompCtr use. Maybe there's an option for it in the latest revision but as yet I've not installed 5.6.2 so can't check. You can effectively ignore my ST comment if you're not using it. It was only for future reference in case you met that issue later.

    Tuesday 10 February, 2015