Add new artifact attribute data type in DNG for specific PA using API
Hello All,
Could you please help me out in adding new artifact attribute data type in DNG for specific PA using REST/OSLC API.
E.g.: New enumeration value of artifact attribute data type to be added.
Please also let me know the reason whether it possible through OSLC API/REST API?
Also let me know the procedure.
Any help is greatly appreciated.
Thanks.
Could you please help me out in adding new artifact attribute data type in DNG for specific PA using REST/OSLC API.
E.g.: New enumeration value of artifact attribute data type to be added.
Please also let me know the reason whether it possible through OSLC API/REST API?
Also let me know the procedure.
Any help is greatly appreciated.
Thanks.
10 answers
Hi Shriraam Balasubramanian
I would propose submitting an enhancement request for the API for 'useful' functions. Automating this kind of activity across multiple projects and modules is a must for larger companies - having to use the GUI would be a catastrophe.
I would propose submitting an enhancement request for the API for 'useful' functions. Automating this kind of activity across multiple projects and modules is a must for larger companies - having to use the GUI would be a catastrophe.
Hi Shriraam Balasubramanian
I don't have the answers - I am also searching for answers to similar questions as you.
I come from a DOORS9/DXL background - by comparison the DNG API is very basic.
IBM cannot possibly provide all end-user required functionality in a timely manner themselves - providing a more powerful API will enable end-users themselves to address this need. This was a good feature of DOORS 9 which has not yet been made available in DNG, leaving it a much less convincing tool option.
We are also compiling a list of needed API enhancements but looking at the turnaround time for enhancement requests it may take quite some time to get them implemented - all the more reason to concentrate on developing the API so end-users can take some of the development load.
I don't have the answers - I am also searching for answers to similar questions as you.
I come from a DOORS9/DXL background - by comparison the DNG API is very basic.
IBM cannot possibly provide all end-user required functionality in a timely manner themselves - providing a more powerful API will enable end-users themselves to address this need. This was a good feature of DOORS 9 which has not yet been made available in DNG, leaving it a much less convincing tool option.
We are also compiling a list of needed API enhancements but looking at the turnaround time for enhancement requests it may take quite some time to get them implemented - all the more reason to concentrate on developing the API so end-users can take some of the development load.
While DNG carries a name similar to DOORS, it is a different product and you need to change your mind set when switching to a new product.
After so many posts, a clear user case has not been identified, and you only kept asking for the API. Have you ever considered alternatives?
For example, if the purpose is to create projects based on a template, you can use a project template with all the customization built in.
After so many posts, a clear user case has not been identified, and you only kept asking for the API. Have you ever considered alternatives?
For example, if the purpose is to create projects based on a template, you can use a project template with all the customization built in.
Hi Donald
Understood that you can create a new project from a project template but...
There seems to be an IBM assumption that 1 R&D project in an organization = 1 DOORS NG project and that changes during the project are none/minimal - this is not necessarily a correct assumption.
Understood that you can create a new project from a project template but...
There seems to be an IBM assumption that 1 R&D project in an organization = 1 DOORS NG project and that changes during the project are none/minimal - this is not necessarily a correct assumption.
-
In large organizations, one R&D project could easily be 30 workpackages each containing 30-40 modules, giving 900-1200 modules per R&D project in a typical scenario. There is no way in the world we will manage that under a single DNG project, especially when there is no longer a module baseline capability. This means our setup would best be split into 1 DNG project per workpackage/sub-project.
- Our typical R&D project lifetime is 3-4 years with resources coming and going and constantly subject to the need to improve way-of-working efficiency.
Comments
I have to read your post several times to understand the use case. Does it mean that you have multiple projects that will get the same new artifact type at some stage? If so, process configuration sharing may be a better solution than using API - in other words, all child projects inherit the process configuration from the parent project. RTC has had this feature for many years, but DNG really falls short in this area. I believe some users have already requested for this feature but I cannot locate the enhancement work item.
Hi Donald
(For some reason the IBM website is not letting me reply to your last comment, so I post my reply here separately.)
Thanks for your answer - your understanding of the use-case is correct.
The concept of inheritance is interesting but would need another feature we look for to be able to make it work -> a project must be able to contain other projects (hierarchy) as a pre-requisite for inheritance.
This would still only give us a partial solution though, as a re-usable component will exist in a DNG project and that would be linked to multiple other 'higher-level' projects not under the same product hierarchy.
The best answer for us would be to enable cross-project copy/update.
(For some reason the IBM website is not letting me reply to your last comment, so I post my reply here separately.)
Thanks for your answer - your understanding of the use-case is correct.
The concept of inheritance is interesting but would need another feature we look for to be able to make it work -> a project must be able to contain other projects (hierarchy) as a pre-requisite for inheritance.
This would still only give us a partial solution though, as a re-usable component will exist in a DNG project and that would be linked to multiple other 'higher-level' projects not under the same product hierarchy.
The best answer for us would be to enable cross-project copy/update.