Closed smuellerDD closed 2 months ago
This is on Demo? Would you be able to run it again or provide the date you ran it originally?
Also the limitEntropyAssessment
field is not expected here. The certificate already has a designation.
@smuellerDD The URL you used is incorrect. It is missing the certify
part. The correct URL is /esv/v1/certify/updatePUD
.
Thanks for the URL. After applying this URL, my client sends:
[
{
"esvVersion":"1.0"
},
{
"supportingDocumentation":[
{
"sdId":65427,
"accessToken":"youwish"
}
],
"limitEntropyAssessmentToSingleModule":false,
"entropyId":"LRNG",
"entropyCertificate":"E1"
}
]
And the server now responds:
[
{
"esvVersion": "1.0"
},
{
"status": "error",
"errors": {
"errorList": [
"supportingDocument has error(s)."
],
"updatePUDSupportingDocumentReferences": {
"messageList": [
"RequiredPropertyError: supportingDocument was not found in the JSON payload."
]
}
}
}
]
Session ID: 5153 as well as 5278
@smuellerDD Please see the UpdatePUD example below and update your request message.
Notice supportingDocument
property is singular named property and only an object, not an array.
[
{
"esvVersion": "1.0"
},
{
"entropyCertificate": "E999",
"entropyId": "0000",
"supportingDocument":
{
"sdId": sdId1,
"accessToken": "<jwt-with-claims-for-sdId1>"
}
}
]
Am Dienstag, 28. Mai 2024, 14:53:03 MESZ schrieb Sunil K Bhaskarla:
Hi Sunil,
@smuellerDD Please see the UpdatePUD example below and update your request message. Notice
supportingDocument
property is singular named property and only an object, not an array. ``` [ { "esvVersion": "1.0" }, { "entropyCertificate": "E999", "entropyId": "0000", "supportingDocument": { "sdId": sdId1, "accessToken": "" } } ]
Does that mean that one an only provide one supporting document? I am wondering that if multiple SD's are provided, do we have to perform multiple individual operations?
In general, I would be wondering why there is a difference to the supportingDocument handling compared to the general publication operation.
Ciao Stephan
Hi Stephan,
Only one PublicUseDocument SD type is required for UpdatePUD.
I have some general information below for now, but @celic will be able to answer your multiple SD question later.
"This certify request allows a user to request that a new Public Use Document (PUD) is attached to an existing certificate. This can be helpful for corrections or rebranding. There is no cost recovery associated with this request. When the PUD is uploaded to the supportingDocumentation endpoint, the document must be uploaded with the PUD document type. Please include a comment on what changed in the document compared to the existing PUD. This will greatly expedite the review process."
Thanks, Sunil
We only want the one updated PUD to be included in the UpdatePUD request. There is no need for anything else for this submission type. Any document differences can be pointed out in the comment field during the supportingDocumentation upload.
Am Dienstag, 28. Mai 2024, 14:53:03 MESZ schrieb Sunil K Bhaskarla:
Hi Sunil,
Sorry for the delay. I finally got around to implement the update
The request now looks like:
[
{
"esvVersion":"1.0"
},
{
"supportingDocument":[
{
"sdId":65756,
"accessToken":"youwish"
}
],
"limitEntropyAssessmentToSingleModule":false,
"entropyId":"LRNG",
"entropyCertificate":"E1"
}
]
Test session is 5446.
The server response is:
[
{
"esvVersion": "1.0"
},
{
"errorMessage": "An unexpected exception occured.",
"success": false
}
]
Ciao Stephan
Pretty close, you just need to remove the limitEntropyAssessmentToSingleModule
and change supportingDocument to an object. I've edited your message payload to reflect those changes:
[
{
"esvVersion":"1.0"
},
{
"supportingDocument":
{
"sdId":65756,
"accessToken":"youwish"
},
"entropyId":"LRNG",
"entropyCertificate":"E1"
}
]
Confirmed, working
The PUD Update operation returns an error for me when I use the following request:
The used URL is: /esv/v1/updatePUD
The server answers: