I am currently developing some Javacode that reassigns workflows that belong to a case in a FileNet 5.0 system.
In some cases I get the following error in the logs:
[FNRPE2131090209E]WorkObject Operation is not valid in this context.
WorkObjectOperation is only valid when an instruction sheet interpreter update function is called. That happens when a WobUpdateUnlocked occurs. In any other case, this exception is thrown. for
If I google the error I only find a few hits that specify this error but it does not give a clear reason to what is the situation for this error.
It is thrown when I execute the vwWorkObject.doReassign() call.
Does someone know what the state is that is causing this error.
as it turns out this exception means that your workflow is in either a waitfor or delay condition before comming to an assign step.
This took me a while to figure out, but in my case it means that I can just ignore this situation, as there is no need for a reassign as the system is going to do it for me as soon as the workflow reaches the assign step.
Related
I have an Oracle Forms 11 g application running on Weblogic server. The default form/login page has a few PL/SQL triggers that simply will not fire. The rest of the configuration seems successful.
Can anyone give me pointers as to where to start looking?? Thanks in advance.
As their name suggests, triggers fire when something triggers them. For example,
a WHEN-BUTTON-PRESSED trigger is triggered by pushing a button
a POST-QUERY trigger fires after executing a query in a data block
a WHEN-NEW-FORM-INSTANCE trigger fires when the form is being run
and so on.
Therefore, make sure that triggers really are triggered. The fact that you have them doesn't mean that they'll run, just because.
In order to find that out, you have two options:
run a form in debug mode:
in one of the triggers (for example in a WHEN-NEW-FORM-INSTANCE) set a breakpoint by right clicking its left margin (you'll see what to do next)
then run the form; that green toolbar icon you use to run it shouldn't be used, but the one next to it, with something reddish on it
as soon as execution gets to the breakpoint, it'll stop, you'll be transferred to Forms Builder, a debug console will open and will let you navigate through the rest of the code step-by-step
do that, and you'll know what's going on, i.e. whether those triggers are called and what they do
as of you being suspicious: did you, by any chance, put some exception handlers that use WHEN OTHERS THEN NULL or something similar? If so, get rid of them. Even if an exception is raised (such as NO_DATA_FOUND or TOO_MANY_ROWS, just to mention two of the most popular and frequent ones), THEN NULL will silently mask it
another one is to put MESSAGE calls into the triggers, such as
begin
message('running WBP trigger: step 1');
... the rest of your code goes here
end;
Doing so, message-after-message will raise an "alert" on the screen (as you'll have to click OK that you saw what it said), and you'll quickly see which triggers fired and which did not. Then investigate it further - debugging described previously will help.
If none of that helps, you'll have to describe what's going on, but this time providing some more info. What you wrote isn't very descriptive. Anyway, best of luck.
I am running DB queries in the UFT framework. During the execution, if the data is deleted in the backend tables, then UFT will throw the error message box as like below. I want to skip the error and continue and report the error description in the xml result sheet.
Error Message:
Run Error:
Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record
I am trying to add by recovery scenario by calling error function and proceed to next step. My error function is as like below:
Function RecoveryFunction1(Object, Method, Arguments, retVal)
If err.number<>"" then
error1=err.description
Reporter.reportevent micwarning,"Error ocurred:","","Error Details: "&error1&"
End If
End Function
I have added the above function in the function library and associated the recovery scenario in the test settings. But still error message is throwing up.
Please help me to handle the error message during run time instead of writing for each and every function 'on error resume next' statement.
You need to change the way you request the view of the database so that later modifications or deletions will not affect your query.
Take a look at the docs for the ADO Recordset. It specifies different cursor types, some of which will allow you to keep a static view of the data as it was when you ran the query, while others give live views. I'm not sure which one is best for your specific use case, so you should experiment and see which one works for you.
Failing that, you can try a move heavy-handed approach which is to begin a database transaction before you do your select, which should isolate your data processing from any external changes. However, that may be undesirable if your process takes a long time, as it may lock out other processes until you end your transaction and yield the locks on the rows you're looking at. Again, it depends on your specific database environment and the systems that interact with it.
In my project I have the following code snippet
if(strcmp(msg->getName(),"failedAck") == 0 || ......)
{
msg->removeControlInfo();
msg->setControlInfo(info);
recvControls++;
sendDirect(msg, table, "ackIn");
}
Essentially the a message arrives at its final destination (lets call it A*), and if it is a type of specified messages, it is sent to another module (B*) which uses the information it carries to perform an operation.
The problem I am having is that after sending the message to the other B*, I delete the message after I am done using it. However, it still appears as part of A* when I look in the inspector. And when I try and delete the message in A* I get an error message saying can't delete the message because it is currently scheduled.
I can't figure out why this happens, Does this mean that sendDirect() does not change the ownership of the message (contrary to the manual)?
Help in this matter will be greatly appreciated, currently dealing with memory management issues in my simulation, and this is a part of it.
I would like to withdraw this question and say thanks to everyone who looked at it. I just recently discovered that the items were being deleted when they were supposed to be. however, i had forgotten that i was making a clone of the object for other uses, that why it was showing up in the inspector. My apologies.
Is there any downside to using a promise with only .catch section, but without .then at all?
I'm asking about the cases where the resolution result is not needed, only error handling.
Is this a good pattern to rely on .catch only and skip .then?
Or is it something that depends on which promise implementation it is?
Conceptually, there's nothing wrong with an operation that only has an error handler and has nothing else to do upon successful completion. If that's all it needs, then that's fine. For example, suppose you're updating a server with some new data from the client. If the data is successfully sent to the server, there's nothing else to do because the operation is complete, but if there's an error, then there is perhaps something else to do (retry, inform the user, correct the data based on the error code, etc...).
To comment on whether that's the right way to design your specific code, we'd have to see the actual code and understand what it is doing and then form an opinion on whether that is the best way to structure that specific code.
If I was designing a general purpose function, I'd certainly provide both completion (resolving the promise) and error (rejecting the promise) so the caller could hook into either one. But it is really up to the caller which events they want to know about and if only the error matters, then just having a .catch() is fine.
I have a React.js application that I am refactoring to use the Flux architecture, and am struggling to figure out how error handling should work while sticking to the Flux pattern.
Currently when errors are encountered, a jQuery event 'AppError' is triggered and a generic Error Handling helper that subscribes to this event puts a Flash message on the user's screen, logs to the console, and reports it via an API call. What is nice is I can trigger an error for any reason from any part of the application and have it handled in a consistant way.
I can't seem to figure out how to apply a similar paradigm with the Flux architecture. Here are the two particular scenarios I'm struggling with.
1) An API call fails
All of my API calls are made from action creators and I use a promise to dispatch an error event (IE 'LOAD_TODOS_FAILED') on failure. The store sees this event and updates it's state accordingly, but I still dont have my generic error behavior from my the previous iteration (notifications, etc).
Possible resolution:
I could create an ErrorStore that binds to the 'LOAD_TODOS_FAILED' action, but that means every time I have a new type of error, I need to explicitly add that action to the ErrorStore, instead of having all errors be automatically handled.
2) Store receives an unexpected action
This is the one I'm really confused about. I want to handle cases when an action is dispatched to a Store that does not make sense given the Store's current state. I can handle the error within the Store to clean up the state, but still may want to trigger an error that something unexpected happen.
Possible resolutions:
Dispatch a new action from the store indicating the error.
I believe Stores are not suppose to dispatch actions (let me know if I'm wrong), and I still have the same issue as with an API error above.
Create a ControllerView for Error Handling that subscribes to every Store
I could define an errors property on every store, then have a View watching every Store and only act on the errors property. When the errors property is not null, it could dispatch new actions, etc. The disadvantages are that I need to remember to add every Store to this view whenever new ones are created, and every store has to have an error property that behaves the same way. It also does nothing to address API call failures.
Does anyone have a suggested approach for a generic Error Handler that fits into the Flux architecture?
TL;DR
I need to handle errors in most Action Creators and Stores. How do I setup consistent error handling that will occur for any type of generic error?
API call fails
If you want to avoid listing every error action in the ErrorStore, you could have a generic APP_ERROR action, and have properties of that action that describe it in more detail. Then your other stores would simply need to examine those properties to see if the action is relevant to them. There is no rule that the registered callback in the stores needs to be focused on the action's type, or only on the type -- it's just often the most convenient and consistent way of determining if an action is relevant.
Store receives an unexpected action
Don't issue a new action in response to an action. This results in a dispatch-within-a-dispatch error, and would lead to cascading updates. Instead, determine what action should be dispatched ahead of time. You can query the stores before issuing an action, if that helps.
Your second solution sounds good, but the dangerous thing you mentioned is "When the errors property is not null, it could dispatch new actions, etc" -- again, you don't want to issue actions in response to other actions. That is the path of pain that Flux seeks to avoid. Your new controller-view would simply get the values from the stores and respond by presenting the correct view.