REST case creation error: "create-audit" was not found (293) (7211)

[talia]

Hi,

I am creating and populating an NBE through Proclaim REST Services.

The NBE is opened successfully and all PUT requests to the Data endpoint return HTTP 200 with Proclaim status OK.

However, the subsequent Save request fails:

POST /rest/ProclaimCaseService/Update
{
"cCaseType": "caseType",
"cCaseNumber": "caseNumber",
"cOperation": "Save"
}
Proclaim returns HTTP 500:
"_errorMsg": "ERROR condition: ** \"create-audit\" was not found. (293) (7211)",
"_errorNum": 293

I am not sending "create-audit" as an operation or referencing it anywhere in the client request. The operation sent is Save.

After the Save failure, the client attempts an Unlock as cleanup. That also returns the same "create-audit" error, presumably because Unlock also invokes the Proclaim update/commit process.

The sequence is:
Logon
Open/Lock NBE
PUT multiple fields - all return OK
Update with Save - HTTP 500, "create-audit" was not found
Update with Unlock as cleanup - same HTTP 500
Logout - OK

Has anyone encountered this error during a REST Save or Unlock?

Thanks

[steve]

It may be unrelated, but can we rule out the sequence of your calls:
creating a new matter using /ProclaimCaseService/Open with cOperation:CREATE will return the newly created matter auto-number-sequence reference, but will not commit it to the DB.

Calling putData via /ProclaimCaseService/Data/:CaseNo will fail until you have first performed a /ProclaimCaseService/Update with coperation: SAVE,LOCK

the required sequence when performing individual open/update calls is:
GET /ProclaimStandardService/Logon (returns cSessionId)
POST /ProclaimCaseService/Open "cOperation":"CREATE" (returns cCaseNo)
POST /ProclaimCaseService/Update "cOperation": "SAVE,LOCK" (commits matter to DB, maintains lock to the session)
PUT /ProclaimCaseService/Data/:CaseNo {fields as required, or put screen data}
POST /ProclaimCaseService/Update "cOperation":"SAVE,UNLOCK" (commits change, releases case_record lock)
POST /ProclaimStandardService/Logout

but perhaps you are actually doing this already if you say your PUT of multiple fields is happy. Are you using CaseService/Data/:CaseNo or CaseService/Data/Screens/:CaseNo to populate field data?

[talia]

It may be unrelated, but can we rule out the sequence of your calls:
creating a new matter using /ProclaimCaseService/Open with cOperation:CREATE will return the newly created matter auto-number-sequence reference, but will not commit it to the DB.

Calling putData via /ProclaimCaseService/Data/:CaseNo will fail until you have first performed a /ProclaimCaseService/Update with coperation: SAVE,LOCK

the required sequence when performing individual open/update calls is:
GET /ProclaimStandardService/Logon (returns cSessionId)
POST /ProclaimCaseService/Open "cOperation":"CREATE" (returns cCaseNo)
POST /ProclaimCaseService/Update "cOperation": "SAVE,LOCK" (commits matter to DB, maintains lock to the session)
PUT /ProclaimCaseService/Data/:CaseNo {fields as required, or put screen data}
POST /ProclaimCaseService/Update "cOperation":"SAVE,UNLOCK" (commits change, releases case_record lock)
POST /ProclaimStandardService/Logout

but perhaps you are actually doing this already if you say your PUT of multiple fields is happy. Are you using CaseService/Data/:CaseNo or CaseService/Data/Screens/:CaseNo to populate field data?

Im using CaseService/Data:CaseNo to populate field data. I figured out after testing that it only happens on .Correspondent index fields and only throws the error when trying to Unlock the New Business Enquiry but the save works perfectly fine. Everything is running on the same session all the other PUT and POST fields work its just when getting to the last Unlock it throws an error.

[steve]

sadly I can't replicate your error here on 3.5.1.20

GET /ProclaimStandardService/Logon
POST /ProclaimCaseService/Open
"cOperation": "CREATE"
POST /ProclaimCaseService/Update
"cOperation": "SAVE,LOCK"
PUT /ProclaimCaseService/Data/:CaseNo
"cFieldName": "Source.Correspondent Index",
"cFieldValue": "123456"
(presuming you know the exact pre-existing correspondent index you want to write to?)
POST /ProclaimCaseService/Update
"cOperation": "SAVE,UNLOCK"
works fine, regardless of whether the Source correspondent in DB maint is ticked for audit this field or not.

If you can reproduce the problem then raise with Access and let us know what they say.

The file "create-audit" lives in the Proclaim programs folder Classic\Appserver\pdata. Check this exists for the Startup Parameter and Environment Settings of your PASOE instance hosting the Proclaim webservices?

[talia]

Hi Steve,

Thanks for testing that.

I did some more investigation and managed to narrow it down further.

The NBE creation, SAVE,LOCK, all field updates, and SAVE all complete successfully. The error only occurs during the final SAVE,UNLOCK, and only when a .Correspondent Index field has been populated.

For example, setting:
{
"cFieldName": "Client (global).Correspondent Index",
"cFieldValue": "135574"
}
returns OK from the Data endpoint, and the correspondent link appears to be written correctly.

The subsequent SAVE,UNLOCK then returns:
{
"_errors": [
{
"_errorMsg": "ERROR condition: ** \"create-audit\" was not found. (293) (7211)",
"_errorNum": 293
}
]
}
I've confirmed that removing the Correspondent Index update allows SAVE,UNLOCK to complete successfully.

I will check whether the create-audit file exists in the PASOE Classic\Appserver\pdata folder as you suggested.
One question: if a Correspondent Index field has auditing enabled, would SAVE,UNLOCK be expected to invoke create-audit at that point? I'm wondering whether the correspondent update is triggering an audit routine that isn't available to the REST service environment.

Thanks.

[steve]

I don't know whether create-audit is called on every commit (SAVE,UNLOCK) regardless of the 'audit this field' flag in DB Maintenance.
I can update a .Correspondent Index field without errors regardless of the audit flag setting, but you could try toggling it or writing to a new correspondent field that doesn't have audit enabled and see if the error remains. This might help Access pinpoint the error, but doesn't help you in the short term.
Let us know what Access support say