I added compatibility level FULL on a subject and now I want it removed, so the schema-registry compatibility level (global compatibility level) is used. How can it be done?
According to the documentation updating compatibility level for the specified subject is done by 'PUT /config/(string: subject)' + {"compatibility": "FULL"}.
When I try:
{
"compatibility": ""
}
as body it returns :
{
"error_code": 42203,
"message": "Invalid compatibility level. Valid values are none, backward, forward and full"
}
and if I try empty body:
{
"error_code": 422,
"message": "updateSubjectLevelConfig.arg3 may not be null (was null)"
}
Can someone help?
I checked out schema registry code and in ConfigResource compatibility level received from the request and is parsed against a CompatibilityLevel enum. So, it is either a valid config (none, full...) or exception is thrown (when null). Also, I couldn't find any other rest end point in rest resources that can allow the deletion of this configuration.
Related
I have following host file:
{
"version": "2.0",
"extensions": {
"queues": {
"maxPollingInterval": "00:00:02",
"visibilityTimeout": "00:00:30",
"batchSize": 16,
"maxDequeueCount": 3,
"newBatchThreshold": 8
}
}
}
I would expect with setup there could never be more than batchSize+newBatchThreshold number of instances running. But I realized when messages are dequed they are run instantly and not just added to the back of the queue. This means you can end up with a very high amount of instances causing a lot of 429 (to many requests). Is there anyway to configure the function app to just add the dequeded messages to the back of the queue?
It was not related to dequeueCount. The problem was because it was a consumption plan, and then you cant control the amount of instances. After chaning to a Standard plan it worked as expected.
I perform a batch update on an OData v2 model, that contains several operations.
The update is performed in a single changeset, so that a single failed operation fails the whole update.
If one operation fails (due to business logic) and a message returns. Is there a way to know which operation triggered the message? The response I get contains the message text and nothing else that seems useful.
The error function is triggered for every failed operation, and contains the same message every time.
Maybe there is a specific way the message should be issued on the SAP backend?
The ABAP method /iwbep/if_message_container->ADD_MESSAGE has a parameter IV_KEY_TAB, but it does not seem to affect anything.
Edit:
Clarification following conversation.
My service does not return a list of messages, it performs updates. If one of the update operations fails with a message, I want to connect the message to the specific update that failed, preferably without modifying the message text.
An example of the error response I'm getting:
{
"error":{
"code":"SY/530",
"message":{
"lang":"en",
"value":"<My message text>"
},
"innererror":{
"application":{
"component_id":"",
"service_namespace":"/SAP/",
"service_id":"<My service>",
"service_version":"0001"
},
"transactionid":"",
"timestamp":"20181231084555.1576790",
"Error_Resolution":{
// Sap standard message here
},
"errordetails":[
{
"code":"<My message class>",
"message":"<My message text>",
"propertyref":"",
"severity":"error",
"target":""
},
{
"code":"/IWBEP/CX_MGW_BUSI_EXCEPTION",
"message":"An exception was raised.",
"propertyref":"",
"severity":"error",
"target":""
}
]
}
}
}
If you want to keep the same exact message for all operations the simplest way to be able to determine the message origin would be to add a specific 'tag' to it in the backend.
For example, you can fill the PARAMETER field of the message structure with a specific value for each operation. This way you can easily determine the origin in gateway or frontend.
If I understand your question correctly, you could try the following.
override the following DPC methods:
changeset_begin: set cv_defer_mode to abap_true
changeset_end: just redefine it, with nothing inside
changeset_process:
here you get a list of your requests in a table, which has the operation number (thats what you seek), and the key value structure (iwbep.blablabla) for the call.
loop over the table, and call the method for each of the entries.
put the result of each of the operations in the CT_CHANGESET_RESPONSE.
in case of one operation failing, you can raise the busi_exception in there and there you can access the actual operation number.
for further information about batch processing you can check out this link:
https://blogs.sap.com/2018/05/06/batch-request-in-sap-gateway/
is that what you meant?
yaml-cpp team and everyone,
Our product receives an unfixed size of json response from a cloud service provider. We currently used a buffer with 16KB initial size to receive it, then pass it to yaml parser(we are using yaml-0.2.7). We expect yaml parser to throw an exception if the json document is incomplete during parsing and we will double the size of the buffer.
Today, we hit an assertion which shows "Assertion failed: (!m_tokens.empty()), function peek, file .../yaml-cpp-0.2.7/src/scanner.cpp, line 41." when doing parser.GetNextDocument(doc). The json document was incomplete due to small receiving buffer.
After examining the buffer and doing some experiment, I found out if some characters are missing following a certain pattern, the assertion in scanner will be hit during GetNextDocument. Such as for '{"access": "abc"}', if the last '}' is missing, then the assertion will be hit. Same thing happens if it is '{"access":' or '{"access"'. It will not hit the assertion if it is '"{"access":"abc' (note abc does not have the trailing double quote).
Will it help if I upgrade to the latest 0.5.3 version? I looked at the source code and saw the same assertion in Scanner::peek function is still there.
Here is the source code of the function where assertion is hit:
Token& Scanner::peek() {
{
EnsureTokensInQueue();
/** THIS ONE GOT HIT **/
assert(!m_tokens.empty()); // should we be asserting here? I mean, we really just be checking
// if it's empty before peeking.
#if 0
static Token *pLast = 0;
if(pLast != &m_tokens.front())
std::cerr << "peek: " << m_tokens.front() << "\n";
pLast = &m_tokens.front();
#endif
return m_tokens.front();
}
Much appreciate for the help! :)
This is fixed in 0.5.3, although I'm not sure when precisely it was fixed. I added tests for your examples and they pass (by throwing exceptions) as expected.
I'm trying to add error codes to one of my project like this:
typedef enum {
FSChatErrorChatManagerInUse = 101,
FSChatErrorFailedToRetrieveHeader = 202,
FSChatErrorFailedToGetCount = 303,
} FSChatErrorCode;
Then, send:
NSError * err = [NSError errorWithDomain:#"Failed To Get Count"
code:FSChatErrorFailedToGetCount
userInfo:nil];
So when notified of an error, you can see what kind it is:
if (err.code == FSChatErrorFailedToGetCount) {
// do stuff
}
Question
Is there some sort of standard error code syntax or numbering I should follow? I'm having a hard time finding a reference.
This page has a nice discussion of this subject:
Like exit status codes, an NSError -code signals the nature of the
problem. These status codes are defined within a particular error
domain, in order to avoid overlap and confusion. These status codes
are generally defined by constants in an enum.
For example, in the NSCocoaErrorDomain, the status code for an error
caused by NSFileManager attempting to access a non-existant file is 4,
as defined by NSFileNoSuchFileError. However, 4 in NSPOSIXErrorDomain
refers to a POSIX EINTR, or "interupted function" error.
So, since you're using your own error domain, you can create whatever error codes you want. By the way, in your example you seem to be misusing the domain value: it's not meant to contain an error message.Use userInfo[NSLocalizedDescriptionKey] for that.
I try to get information from Yodlee API.
I have a test user where I've implemented adding an account and I got refresh OK from the site:
{ siteRefreshStatus: {
siteRefreshStatusId: 8
siteRefreshStatus: "REFRESH_COMPLETED_WITH_UNCERTAIN_ACCOUNT"
}
- siteRefreshMode: {
refreshModeId: 2
refreshMode: "NORMAL"
}
- updateInitTime: 0
nextUpdate: 1391603301
code: 403
noOfRetry: 0
}
}
Now when I try to perform search and get the actual transactions I get this error:
{
errorOccured: "true"
exceptionType: "com.yodlee.core.IllegalArgumentValueException"
refrenceCode: "_57c250a9-71e8-4d4b-830d-0f51a4811516"
message: "Invalid argument value: Container type cannot be null"
}
The problem is that I have container type!
Check out the parameters I send:
cobSessionToken=08062013_2%3Ad02590d4474591e507129bf6baaa58e81cd9eaacb5753e9441cd0b1ca3b8bd00a3e6b6a943956e947458307c1bb94b505e2eb4398f890040a3db8c98606c0392&userSessionToken=08062013_0%3A8e8ef9dd4f294e0f16dedf98c1794b96bf33f2e1f2686eda2f35dfe4901dd3a871eed6d08ce52c99a74deb004c025ebf4bf94c7b17baf8ba18aacb331588f5f5&transactionSearchRequest.containerType=bank&transactionSearchRequest.higherFetchLimit=1000&transactionSearchRequest.lowerFetchLimit=1&transactionSearchRequest.resultRange.endNumber=500&transactionSearchRequest.resultRange.startNumber=1&transactionSearchRequest.searchClients.clientId=1&transactionSearchRequest.searchClients.clientName=DataSearchService&transactionSearchRequest.ignoreUserInput=true&transactionSearchRequest.searchFilter.currencyCode=USD&transactionSearchRequest.searchFilter.postDateRange.fromDate=01-01-2014&transactionSearchRequest.searchFilter.postDateRange.toDate=01-31-2014&transactionSearchRequest.searchFilter+.transactionSplitType=ALL_TRANSACTION&transactionSearchRequest.searchFilter.itemAccountId+.identifier=10008425&transactionSearchRequest.searchClients=DEFAULT_SERVICE_CLIENT
There is an error occurred while adding the account, which can be interpreted by this parameter code: 403 and hence you will not be seeing that account when you call the getItemSummary API. An account is successfully linked if the code has zero as value. E.g.code:0 . 403 is an error which is show if Yodlee's data agent has encountered an unhandled use case. Hence for any such error you should file a service request using Yodlee customer care tool.
To know more about error codes please visit -
https://developer.yodlee.com/FAQs/Error_Codes
The status is show as completedsiteRefreshStatus: "REFRESH_COMPLETED_WITH_UNCERTAIN_ACCOUNT"because addition of any account is followed by a refresh in which Yodlee's data agent logs into the websites of FIs and try scraping data. Hence completion of this activity is denoted as REFRESH_COMPLETED even when there is an error occurred.
TranasctionSearch issue -
I can see two of the parameters with a "+" sign. Since transactionSlipttype and containerType are dependent on each other the error is thrown.
&transactionSearchRequest.searchFilter+.transactionSplitType=ALL_TRANSACTION
&transactionSearchRequest.searchFilter.itemAccountId+.identifier=10008425
The right parameters are -
&transactionSearchRequest.searchFilter.transactionSplitType=ALL_TRANSACTION
&transactionSearchRequest.searchFilter.itemAccountId.identifier=10008425