8

One of our Schemas changed, a new metadata field called "Date" was added, as a MANDATORY one (minOccurs=1). - all the components using this schema are missing now the content for this mandatory field.

When we open such a component using this changed schema, where this new mandatory field was added to, and we try to save it without change, we got a message that "Date" must be filled out. We are forced to add a value to this Date field before we can save any other changes to these components.

General questions:

  1. Above scenarios are common I suppose, how are these handled?

  2. I read about "component synchroniser" tool which could be used in theory in such cases. a) How would that work and solve our issues? It would be able to add this new missing field values to our component using this changed schema? b) So after running this "component synchroniser" tool all our components would contain this "Date" metadata field?

Translation Manager related questions:

  1. What would happen in the translation process using Translation Manager, if we would select a content component with such a missing metadata field "Date" and send a translation job?

    • I guess it would fail to send the translation job, but would like to get some direct experiences about such scenarios described above.
    • Or it would actually extract the components contnet even if that madnatory metadata field is missing from the component, but in this case it would fail at the "import" step, right?
  2. How are such situations handled by the Translation Manager itself? What about we select a complete folder with content components and there may be only some of such components inside? Will it give an error message and will fail the complete translation process/job, or will fail only for those components which are missing this mandatory field "Date"?

We don't have yet Translation Manager, I tried to check through already all the docs I have, but was unable to get direct information about scenario I described above...

Thanks in advance!

bvl

4

Not sure about the SDL Tridion version but in such scenario, I would first recommend doing a complete Impact Analysis of change in the schema - if the field is non-mandatory then there would not be a problem generally but if you are adding a mandatory field then you must identify all the impact of this change before doing it and also should have taken a decision on how do you manage the existing components for this field, there are following options that you can try and then take decision on:

  • Manual Update of existing component for the newly added field - works if the number of components are small
  • Providing default value for the field while adding this in the schema - Not 100% sure if this option works as not sure about your SDL Tridion version and there were some issue with this in the SDL Tridion 2011
  • Use some tool available as open source which will update the component and provide the values in it
  • Write your custom tool using core service (or TOM API if SDL Tridion 2009), which accept the schema name & open, update and save all components based on it - Should be a small and simple implementation
  • +1 for recommending first to do it manually - often takes a lot less time than scripting around it. – Nuno Linhares Nov 11 '13 at 2:31
  • Thanks, Pankaj! What interests me is exactly SDL Tridion 2011 and even more how Translation Manager works in such scenarios? – BVL Nov 11 '13 at 7:04
  • sorry but not much experience with TM – Pankaj Gaur Nov 11 '13 at 7:06
4

"Component synchroniser" will help you only in case if your mandatory field has default value. In this case "Component synchroniser" will update components. If this field has no dafult value tool can not update them

TM does not transalte fields with Date type but it still will have problems with translating them because it need to save whole component on retrieve

TM behave diferently depend on version:

In 2013 release (7.0) and previous TM will send this components without errors and on retrieve step it will fail. After "retry retrive" it should retrive other "non-error components"

In 2013 SP1 release (7.1) TM will fail on send and you will see list of all error components in error list of translation job. (whole job will fail with error list containing "error components")

Also TM (7.1) run this "Component synchroniser" before send and after retrieve but still it can only fix this components if mandatory filed has default value

With out default value nothing can fix this components for you. Unless you will make some custom tool or Event system handler to handle this situation.

If you already have some of these components in translation you can change your schema to not have mandatory field, then retrive and change schema back. If you do not send them yet it`s better to fix them before

  • Yuri, thanks for your answere, so I think we are stucked here a little. Great answere, if possible I would accept both yours and Barts answere... – BVL Nov 11 '13 at 10:37
  • Yuri, do you know how could I validate the xml components against their schema? I would like to get a list of components which are failing to validate...programatically through core services or other way if possible.I'm trying to save components to local file system automatically and also XSD's and then run a validator localy, but I'm failing at the moment to get XSD dependencies like cm_xml_inst.xsd, which I cant resolve so validation fails because of that too.please: tridion.stackexchange.com/questions/3476/… Thanks! – BVL Nov 11 '13 at 13:10
3

To start with the most obvious, when you opened your Schema for edit, you got a warning message:

Changes to this Schema will affect all related items.

It even offered you a Show Where Used button, so you could investigate the impact before doing your change.

Now I know that nobody pays much attention to warning messages, but in this case, it's a simple matter of, you have been warned. Your Schema change (especially adding a mandatory field) is indeed not uncommon, but is is an action which heavily impacts the system and generally is disregarded as trivial (I can just add the field and Save the Schema, no problem right), which it is certainly not. It isn't only Translation Manager where you would see its impact, also Content Porter, but even simply Rendering/Publishing is where you can notice issues after your change.

So on to your questions:

  1. How is it handled? Well preferably you would do an impact analysis before you make the change and determine how much work it is to fix the problem you create (in your case edit all exiting content and add a value to the new field).

  2. Can you use the Component Synchronizer? Yes that would be one of your options.

  3. What would happen in the translation process using Translation Manager? The translation process will go fine (a date would probably not be translated anyways, but if you added a translatable field, then it still wouldn't be offered as it is empty), but TM can NEVER check your Component back in since it is missing a mandatory field. A similar story as with Content Porter, you can export the content just fine, but you can NEVER import it, as it is missing a mandatory field. You have to fix the issue you introduced before sending something for Translation or exporting it.

  4. How are such situations handled by the Translation Manager itself? I believe in 2011 there is basically nothing special done, all content you select for Translation is being sent for Translation AS IS. If that content was invalid (according to its Schema), the result which comes back from TM will fail to save and your Components will stay checked out.

Update

To elaborate further, indeed you should be careful to change an existing Schema when there is already content based on it. However as we all know, you can't always know upfront what you learn later on. So changes will happen, and when they do, just make sure you understand its impact and handle it rather than to ignore it.

As mentioned, you can simply use the Where Used option on the Schema to get a list of all items using that Schema, which is the entire list of items that are impacted by your change. You can get a similar list via the Core Service (see here for an example).

As how to handle it, well that is up to you. As you yourself already mentioned, you can use the Component Synchronizer (or any other tool you find/build) or you can do it manually. It all depend on your change and how many items that will effect.

As for the best way to validate a Components content against its Schema, well let SDL Tridion do that for you. Simply open the Component (in the UI) and click on the Save button. If it saves, it is valid, if not, then read the error message you get (you will get the same when saving it from any of the APIs btw.).

  • Bart, so this scenario, this situation we are facing with is not OK, right? I mean can we say that we should never got into such scenario as this is unacceptable and may have serious consequences in future? Other then as a consequence regarding Content porter and TM, are there other issues we may get into because of this actual state? You mentioned Rendering/Publishing where we may get into problems too, could you please explaing that a little further? Thanks, bvl – BVL Nov 11 '13 at 10:41
  • Is there a way to get a list of such components which doesn't validate with the actual schema? Is there a core service we could use to easily get such a list, or any other thoguhts how to generate a list of these components? Or the only way is to export/save all components and schemas into local files and make a tool/program to validate them all...? In schemas there are "imports" too which make this harder. Would be useful if there would be already some support as part of core service at least to see where we have issues with. Thanks! – BVL Nov 11 '13 at 10:47
  • Bart, I know the "where used" functionality, but what I need is a list of components which are failing to validate and "where used" can't give me that answere. Also what I would need an option to validate the content components agains the schemas and would like to do that programatically, not going one by one by opening a couple hundred of components or more... Also would like to have a solution that I could use next time when we get into similar scenario. Thanks! – BVL Nov 11 '13 at 13:06
  • There is no such thing as a list of Components that are failing to validate (you can build it yourself, but then you have to try to save all Components, the Schema validation is called upon Save). But simply put when you change your Schema, all existing Components based on that Schema are invalid. And as mentioned already, there is no such tool in SDL Tridion to fix your issue, there are third party tools like the mentioned Component Synchroniser and there could be more. – Bart Koopman Nov 11 '13 at 13:31
  • components were created with a correct schema, correct content. "Date" wasnt part of that schema. After a year, the field "Date" was added to the schema as non mandatory! After 6 months, the field "Date" was made mandatory. At the end we have now some components with Date, some without, etc. In short this lead us where we are now at the moment. I wasn't involved/notified earlier regarding any schema changes. :( – BVL Nov 11 '13 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.