It's all about the answers!

Ask a question

Updating enumerated fields using OSLC


Gary Dang (59328349) | asked Oct 14 '11, 1:28 a.m.
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



permanent link
Steve Speicher (30765) | answered Oct 14 '11, 11:06 a.m.
JAZZ DEVELOPER
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

permanent link
Gary Dang (59328349) | answered Oct 14 '11, 4:05 p.m.
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.

permanent link
Geoffrey Clemm (29.3k23035) | 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
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).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.

permanent link
Steve Speicher (30765) | answered Oct 20 '11, 9:09 a.m.
JAZZ DEVELOPER
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.

permanent link
Steve Speicher (30765) | answered Oct 20 '11, 9:11 a.m.
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


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.

permanent link
Gary Dang (59328349) | answered Oct 21 '11, 4:58 p.m.
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 <03:57:27>).</oslc>
<oslc>403</oslc>
</oslc>
</rdf>






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
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).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.

permanent link
Gary Dang (59328349) | answered Oct 21 '11, 5:02 p.m.
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 <04:00:34>).</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.

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 <03:57:27>).</oslc>
<oslc>403</oslc>
</oslc>
</rdf>






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
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).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.

Your answer


Register or to post your answer.