I'm going to log this with product support but it's offline at the moment, and I could do with an urgent answer so thought I'd chance my arm here!
Our company has went live with Items today, hundreds of users creating new items in the Vault. I've set up the Item Numbering Scheme to simply be IA0001, IA0002 etc etc
However, completely randomly, when creating an Item with no CAD file association, it's changing the Item Number to IA0001@TW, it's putting @TW at the end of the Item number! What's this all about?? @TW is categorically not in my Item Numbering scheme. I have a full SQL replicated envionment here and the workgroup name is TW for this site, so clearly this is the workgroup name it's appending to the Item Number, but I have not told it to do this! My numbering scheme is attached, clearly it's not there.
If anyone can think of why this is happening, I'd love an explanation as this is going to cause havoc.
This happens in full replication if items are create on multiple workgroups with the same item number. Vault requires that all item numbers be unique - so if a duplicate item number is replicated over then one of the duplicate item numbers is appended with the workgroup label (label is configurable in ADMS console). This should normally only happen if items are created with the same scheme in close time proximity on multiple workgroups - i.e. before the item has been replicated over.
The alternative to the this reactive model would be to set up the numbering scheme so that there will be no conflicts - e.g. it is possible to always include the workgroup label as part of the numbering schema so generated numbers will always be unique.
Hope this sheds some light on what you are seeing,
Paul - thanks, that does make sense and clears it up but with the greatest respect it's absolutely not good enough. I'm not having a dig at you obviously, as I'm sure you didn't personally design it this way.
I've set up a numbering scheme for Items, I've done that because that's what the company requires Item numbers to be, there's no two ways about that, the numbers MUST be as they are in that numbering scheme. It is absolutely not acceptable for Vault to decide to change my number because of some technical conflict it can't work around. In addition to this, our Items are being exported to IFS (ERP System) and there's no chance it will take any spurious symbols in the part number. And I won't be asking them to change their code to suit this either.
So just so I'm fully understanding this, if someone at site 1 creates an Item they get the number IA0001. If during that time, someone at site 2 creates an Item, they get IA0001@2? So the Vault actually knew that Item number IA0001 was in use, but instead of using the next number in the sequence it puts @[Workgroup] in the number? What's the logic behind this?
In your example, the second site didn't know the item number was in use. It created the item with the number and it wasn't until replication occured that the conflict was detected. i.e.
- Item IA0001 created on workgroup1
- Item IA0001 created on workgroup2 (at or near the same time)
- Item IA0001 replicates to workgroup1
- During replication workgroup1 discovers the item number has already been used, so renames one of the duplicates
- The (modified) item replicates back to workgroup2
This is a pretty simple scenario, but can get more complicated if multiple workgroups are involved (e.g. 4 workgroups create IA0001 at the same time) or multiple items are created (e.g. IA0001 - IA0100 on workgroup1 and IA0001 - IA0200 on workgroup2).
I think the expectation was that customer would either use non-conflicting numbering - e.g. some customers (I believe) drive numbering from ERP not vault so ERP ensures there are no duplicates - or would create a numbering scheme that avoids conflicts (e.g. by including the workgroup label in the scheme itself). In the event of conflicts, I think it was envisioned that in the (expected) few cases this occured that it could be remediated by changing the item number after the fact.
The reasoning behind this was to allow the workgroups to create numbers without having to contact each other and do negotiations prior to being able to create items. One of the intentions behind connected workgroups was to allow the system to be usable if workgroups were temporarily disconnected for periods of time.
I'm not sure I've given you an immediate solution here. I know more about replication and not a great deal about items and how they are used. Hopefully I've at least given you a sense behind how the system works and some of the reasoning behind it..
Hi Paul - thanks for the explanation, it makes perfect sense but still this isn't an acceptable workflow to have in the product. We're using full SQL replication and as far as I know, the document numbering schemes are having no issues with being used across multi-sites so on face value, I can't see why the Item numbering schemes should.
Technically speaking again, I get the 'if a workgroup goes down' theory but to be honest if a business is large enough to justify having multi-site replication, it'll be sitting on a pretty good IT infrastructure so although you can never say never, it's a rare occurence for a site to compeletely go down. However, item's being created is an event that occurs multiple times, hundreds of times per day.
In addition to that, I worked in the reseller channel for nearly a decade and this was never publicised by Autodesk, I had no idea that we needed to consider this when building multi-site implementations. A Google search for "autodesk vault item number replication" returns zero information on this and confirms that I haven't missed an technical publications on this story.
The concept of having a numbering scheme per site isn't a practical one, if you allowed the option of defaulting a specific numbering scheme to a specific site then it would be close to being a considerable option. If it was up to me, I'd consider altering product behaviour to either:
1) Provide an administrative option whereby if a workgroup goes down, prevent any Items being generated. Then it's up to me, if a site goes down I can simply stop Items being made until things come back online.
2) Keep the current existing workflow, but in the event of a disconnection between publisher and subscriber, when the failed site comes back online, Vault creates an ADMS task to automatically renumber any Items created during that time with the [@WORKGROUP suffix], giving them the next available number. Warn all users with an in-client prompt that the Items they're creating may be automatically renumered when the system fault is resolved.
3) Most if not all everyday Vault users are not going to have a clue about what we're talking about here, so when this numbering conflict occurs through standard workflow, at least give them an in-client prompt or warning explaining why their Item number isn't now what they first thought it was.
4) Make the Item numbering schemes work the same way as the document numbering schemes!
I can think of many more options, most of which including the above are all much more favorable than what we have now which is Vault modifying production data at will without any warning to the user.
Document numbering works pretty similar to items (i.e. it is possible to create duplicates with similar workflows). The difference is that because of the folder ownership requirement, there would be no way to create duplicates inside the same folder. As items all live in the same space (no ownership required to create an item), the numbering issue had to be dealt with a bit differently.
While it isn't currently possible to default a different numbering scheme per site, it is possible to include the workgroup label as an element in the numbering scheme - which would assure no conflicts up front. Not sure if you have experimented with that option.
That said, I do understand you have problems with the current approach. And I do appreciate the suggestions you've made. I'm going to pass on your feedback and suggestions to the product manager and designer on this feature. Hopefully we can find a way to improve the experience for you.
Thank you for your feedback in this area. I have added your request to our IdeaStation : Item Number Scheme for Multi-site Environments
i wonder has this been resolved in later versions of vault?
it is kind of hard to believe that the publisher server cannot issue numbers to any workgroup in a consecutive fashion regarless of whether it is replicated or not. is this supposed to be a database or not?
i came across this thread when i started searching for info on what i had hoped was just a bug issue whereby my numbering scheme was dealing me the same auto-number when i added any (variation of) free text option to the end of a number. in such cases we don't really have an auto-number do we? at least not in v2012.
how do we now tell the boss that he has just spent his $$$ on something that behaves like a beginners attempt at a program.
probably means we now need to get rid of any free text input until vault can actually deal out consecutive numbers like it says on the box.
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register
Start with some of our most frequented solutions to get help installing your software.