Updating enumerated fields using OSLC
In the native out of the box defect, I think the Severity field is an enumerated field. If I want to update this field using OSLC, can I just pass the raw string value in the OSLC XML request (e.g. "Normal") or do I have to figure out what the RDF resource URL that represents "Normal" and use that in the XML request (e.g. such as when updating category fields).
|
7 answers
In the native out of the box defect, I think the Severity field is an enumerated field. If I want to update this field using OSLC, can I just pass the raw string value in the OSLC XML request (e.g. "Normal") or do I have to figure out what the RDF resource URL that represents "Normal" and use that in the XML request (e.g. such as when updating category fields). You need to find the valid URI for the choice for the enumeration, I was able to find these choices by: GET https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity?oslc.properties=* Headers: Accept: application/xml (I'd recommend application/rdf+xml but using plain XML for ease of describing here, others may be valid) OSLC-Core-Version: 2.0 I'm not sure the right way to get the URL above, but I got it by first fetching a work item and then looking at its severity attribute and "chopping off" the trailing literal id segment (in other words, stripping off the last '/' and everything to the right of it) Also, I added "?olsc.properties=*" so the URIs (if you will) will be expanded inline and doesn't require additional GETs to fetch details. Which I get a list like: Attachment Then finding the right URI (say for "Normal") would be "https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity/severity.literal.l3" I can then update the original work item by doing a PUT (or a partial put) and don't forget to set the Content-type header to match your content Here's what I did: PUT https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity?oslc.properties=* Headers: Accept: application/xml OSLC-Core-Version: 2.0 Content-type: application/xml Content: Attachment Returned with 200-Ok and change was made. Hope that helps |
In the native out of the box defect, I think the Severity field is an enumerated field. If I want to update this field using OSLC, can I just pass the raw string value in the OSLC XML request (e.g. "Normal") or do I have to figure out what the RDF resource URL that represents "Normal" and use that in the XML request (e.g. such as when updating category fields). You need to find the valid URI for the choice for the enumeration, I was able to find these choices by: GET https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity?oslc.properties=* Headers: Accept: application/xml (I'd recommend application/rdf+xml but using plain XML for ease of describing here, others may be valid) OSLC-Core-Version: 2.0 I'm not sure the right way to get the URL above, but I got it by first fetching a work item and then looking at its severity attribute and "chopping off" the trailing literal id segment (in other words, stripping off the last '/' and everything to the right of it) Also, I added "?olsc.properties=*" so the URIs (if you will) will be expanded inline and doesn't require additional GETs to fetch details. Which I get a list like: Attachment Then finding the right URI (say for "Normal") would be "https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity/severity.literal.l3" I can then update the original work item by doing a PUT (or a partial put) and don't forget to set the Content-type header to match your content Here's what I did: PUT https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity?oslc.properties=* Headers: Accept: application/xml OSLC-Core-Version: 2.0 Content-type: application/xml Content: Attachment Returned with 200-Ok and change was made. Hope that helps Hi Steve, thanks for the reply. Long time no talk. The approach you have indicated is what I feared and the reason is this. Let say I have an external integration program that uses OSLC (or even the IBM Integration Engineering API) to update an enumerated field (with 50 enumerated values) in 100 project areas. Based on the requirement that I need to find out the unique RDF URL for each enumerated value in each and the context path is different for each project area, I will need to make the integration program aware of 50 RDF URLs (each representing a unique value of the enumerated set) for each project area. Does this mean I have to manually find out for each project area what those 50 RDF URLs are? If so, that sounds like a lot of manual work before I can even execute the integration program. I hope I am missing something in the approach and this is actually not a lot of manually discovering work involved. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Oct 15 '11, 10:58 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If there is currently no way to discover those URLs through the OSLC
API, I assume one could use the RTC HTTP API to find them, until that functionality is supported by OSLC? Cheers, Geoff On 10/14/2011 4:08 PM, gdang wrote: sspeichewrote:In the native out of the box defect, I Hi Steve, thanks for the reply. Long time no talk. The approach you have indicated is what I feared and the reason is this. Let say I have an external integration program that uses OSLC (or even the IBM Integration Engineering API) to update an enumerated field (with 50 enumerated values) in 100 project areas. Based on the requirement that I need to find out the unique RDF URL for each enumerated value in each and the context path is different for each project area, I will need to make the integration program aware of 50 RDF URLs (each representing a unique value of the enumerated set) for each project area. Does this mean I have to manually find out for each project area what those 50 RDF URLs are? If so, that sounds like a lot of manual work before I can even execute the integration program. I hope I am missing something in the approach and this is actually not a lot of manually discovering work involved. |
In the native out of the box defect, I think the Severity field is an enumerated field. If I want to update this field using OSLC, can I just pass the raw string value in the OSLC XML request (e.g. "Normal") or do I have to figure out what the RDF resource URL that represents "Normal" and use that in the XML request (e.g. such as when updating category fields). You need to find the valid URI for the choice for the enumeration, I was able to find these choices by: GET https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity?oslc.properties=* Headers: Accept: application/xml (I'd recommend application/rdf+xml but using plain XML for ease of describing here, others may be valid) OSLC-Core-Version: 2.0 I'm not sure the right way to get the URL above, but I got it by first fetching a work item and then looking at its severity attribute and "chopping off" the trailing literal id segment (in other words, stripping off the last '/' and everything to the right of it) Also, I added "?olsc.properties=*" so the URIs (if you will) will be expanded inline and doesn't require additional GETs to fetch details. Which I get a list like: Attachment Then finding the right URI (say for "Normal") would be "https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity/severity.literal.l3" I can then update the original work item by doing a PUT (or a partial put) and don't forget to set the Content-type header to match your content Here's what I did: PUT https://quagmire.rtp.raleigh.ibm.com:9443/ccm/oslc/enumerations/_C0rY8NrnEeC9RqrKMC6bkA/severity?oslc.properties=* Headers: Accept: application/xml OSLC-Core-Version: 2.0 Content-type: application/xml Content: Attachment Returned with 200-Ok and change was made. Hope that helps Hi Steve, thanks for the reply. Long time no talk. The approach you have indicated is what I feared and the reason is this. Let say I have an external integration program that uses OSLC (or even the IBM Integration Engineering API) to update an enumerated field (with 50 enumerated values) in 100 project areas. Based on the requirement that I need to find out the unique RDF URL for each enumerated value in each and the context path is different for each project area, I will need to make the integration program aware of 50 RDF URLs (each representing a unique value of the enumerated set) for each project area. Does this mean I have to manually find out for each project area what those 50 RDF URLs are? If so, that sounds like a lot of manual work before I can even execute the integration program. I hope I am missing something in the approach and this is actually not a lot of manually discovering work involved. Hey Gary, Yes, long time no talk. I suppose some of this can be simplified if you can standardize the values and process definition you use. This should help minimize the conflicts and need to map values. Interestingly enough the OSLC-CM working group is looking at how to define a set of values for severity and priority. It would be good to get your feedback on a few items, namely how many "standard" values should there be and what are they. Just to reiterate for the readers (I know you know), OSLC is driven by participation and scenarios. So scenarios like this help define that but requires someone to drive it through some working groups. |
If there is currently no way to discover those URLs through the OSLC The way one would normally get them is through oslc:ResourceShapes. RTC work items is looking to add this support in 3.5, a preview is available now. There is also some work (see my other reply) to define a spec'd set of values for the properties of severity and priority. Though that is under discussion and no timeline when any produce would support that. |
|
Running into a snag with the POST just to create a record and mapping regular fields (not enumerated). Getting a 403 error.
POST content - <rdf> <rdf> <rtc_cm>myDescription </rtc_cm> <rtc_cm>john.doe@dsaf.com</rtc_cm><rtc_cm>John doe</rtc_cm><rtc_cm>12122</rtc_cm> <rtc_cm> </rdf> </rdf> RESPONSE: <xml> <rdf> <oslc> <oslc>'Save Work Item' failed. Preconditions have not been met: The 'Contact Name' attribute needs to be set (work item &lt;03:57:27&gt;).</oslc> <oslc>403</oslc> </oslc> </rdf> If there is currently no way to discover those URLs through the OSLC sspeichewrote:In the native out of the box defect, I Hi Steve, thanks for the reply. Long time no talk. The approach you have indicated is what I feared and the reason is this. Let say I have an external integration program that uses OSLC (or even the IBM Integration Engineering API) to update an enumerated field (with 50 enumerated values) in 100 project areas. Based on the requirement that I need to find out the unique RDF URL for each enumerated value in each and the context path is different for each project area, I will need to make the integration program aware of 50 RDF URLs (each representing a unique value of the enumerated set) for each project area. Does this mean I have to manually find out for each project area what those 50 RDF URLs are? If so, that sounds like a lot of manual work before I can even execute the integration program. I hope I am missing something in the approach and this is actually not a lot of manually discovering work involved. |
|
Copy and paste error last time.. here is the XML request and response
POST request - <rdf> <rdf> <rtc_cm>myDescription </rtc_cm> <rtc_cm>john.doe@dsaf.com</rtc_cm><rtc_cm>John doe</rtc_cm><rtc_cm>12122</rtc_cm> <rtc_cm> </rdf> </rdf> RESPONSE <xml> <rdf> <oslc> <oslc>'Save Work Item' failed. Preconditions have not been met: The 'Contact Name' attribute needs to be set (work item &lt;04:00:34&gt;).</oslc> <oslc>403</oslc> </oslc> </rdf> Running into a snag with the POST just to create a record and mapping regular fields (not enumerated). Getting a 403 error. If there is currently no way to discover those URLs through the OSLC sspeichewrote:In the native out of the box defect, I Hi Steve, thanks for the reply. Long time no talk. The approach you have indicated is what I feared and the reason is this. Let say I have an external integration program that uses OSLC (or even the IBM Integration Engineering API) to update an enumerated field (with 50 enumerated values) in 100 project areas. Based on the requirement that I need to find out the unique RDF URL for each enumerated value in each and the context path is different for each project area, I will need to make the integration program aware of 50 RDF URLs (each representing a unique value of the enumerated set) for each project area. Does this mean I have to manually find out for each project area what those 50 RDF URLs are? If so, that sounds like a lot of manual work before I can even execute the integration program. I hope I am missing something in the approach and this is actually not a lot of manually discovering work involved. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.