Talend - Error handling without using subjobs - talend

Please see the image.
So here is a flow, wherein the first component executes a database query to find QAR_ID (single row), if it is found then all well. I am trying to put error handling into this. When no rows are found, it directs to tJava_11 which raises an java exception and that gets logged by another tJava component.
The problem I am facing is when it goes to error handling flow, it logs the error and just goes to the post-job section. However, I want Talend to take the OnSubJobOk route so that it continues with other steps instead of directly jumping to post-job section.
I know this is possible using subjobs but I don't want to keep creating 'n' number of subjobs.
Is there any way this can be done in the same job?

You could remove the runif and handle both scenarios in the get_QAR_ID into context component. ie query the database component's NB_LINE after variable, if it's <1 raise the error, else set the value. Your job would then flow to the onSubjobOk.

You can do something like this :
In tJava_1 you do your error logging if no row is returned by your query, and you continue to the next subjob. No need to throw an exception here only to catch it immediately after.
If any row is found, you continue to the next subjob (tJava_2) with an If trigger.

Related

I have to perform more stuff after the parallelization work using Talend Studio. How do I place a connecting OnSubJobOk?

I am trying to implement parallelization within talend. I have it working, but now I don't know how to connect the parallelization work to the next part. Usually, you would click on the previous block and select OnSubjobOk. That option doesn't appear. Is there another component that I need to add that I don't know about?
Under the basic settings of tParallelize you would find the option Wait For. This have two options -
end of first subjob: sequence the relevant subjob to be executed at
the end of the first subjob
end of all subjobs: sequence the relevant subjob to be executed at the end of all
subjobs.
So, all you have to do is connect your next part - your sub job with the tParallelize component by selecting the trigger - synchronize(wait for all). This would ensure once all the parallel subjobs/components are executed the sub job connected with synchronize(wait for all) will be executed.

Akka Persistence: Where do the execution of the Command Goes when it is not simply a state update

Just for clarification: Where do the execution of a command goes, when the execution is not simply a state update (like in most examples found online)
For instance, in my case,
The Command is FetchLastHistoryChangeSet which consist in fetching the last history changeset from an external service based on where we left off last time. In other words the time of the newest change of the previous history ChangeSet Fetched.
The Event would be HistoryChangeSetFetched(changeSet, time). In correlation to what has been said above, the time should be that of the newest change of the newly history ChangeSet Fetched (as per the command event currently being handled)
Now in all example that i see, it is always: (i) validating the command, then, (ii) persisting the event, and finally (iii) handling the event.
It is in handling the event that i have seen custom code added in addition to the updatestate logic. Where, the custom code is usually added after the update state function. But this custom is most of the time about sending message back to the sender, or broadcasting it to the event bus.
As per my example, it is clear that i need to do quite few operation to actually call Persist(HistoryChangeSetFetched(changeSet, time)). Indeed i need the new changeset, and the time of the newest change of it.
The only way i see it possible is to do the fetch in the validating the command
That is:
case FetchLastHistoryChangeSet => val changetuple = if ValidateCommand(FetchLastHistoryChangeSet) persit(HistoryChangeSetFetched(changetuple._1, changetuple._2)) { historyChangeSetFetched =>
updateState(historyChangeSetFetched)
}
Where the ValidateCommand(FetchLastHistoryChangeSet)
would have as logic, to read last changeSet time (newest change of the changeSet), fetch a new changeset based on it, if it exist, get the time of its newest change, and return the tuple.
My question is, is that how it is supposed to work. Validating command
can be something as complex as that ? i.e. actually executing the
command ?
As it says in the documentation: "validation can mean anything, from simple inspection of a command message's fields up to a conversation with several external services"
So I think what you're trying to do is exactly right. Any interaction with an external service must be done at the command validation stage.

How can I know what component failed?

When using the On SubJob Error trigger, I would like to know what component failed inside the subjob. I have read that you can check the error message of each component and select the one that is not null. But I feel this practice is bad. Is there any variable that stores the identity of the component that failed?
I may be wrong, but I'm afraid there isn't. This is because globalVar elements are component-scoped (ie they are get/set by components themselves), not subjob-scoped (this would mean being set by Talend itself, or something). When the subjobError signal is triggered, you loose any component-based data coming from tFileInputDelimited. For this design reason, I don't think you will be able to solve your problem without iterating inside the globalMap searhcing for the error strings here and there.
Alternatively you can use tLogCatcher, which has a 'origin' column, to spot the offending component and eventually route to different recoverable subjobs depending on which component went to exception. This is not a design I trust too much, actually, because tLogCatcher is job-scoped, while OnSubjobError is directly linked to a specific subjob only. But It could work in simple cases

oracle Forms error FRM-40654

When I update a table through a data block, I am getting an error in the parent form "FRM-40654 Record has been updated by another user.Re-query to see change". I have looked into Oracle forums and tried the changes in properties. There are no triggers also. It Forms 6i. How can I trace where exactly the error is happening in the form? I tried to enable the database trace within the form load. But it is not creating trace file. I am opening a data block from the form on a button click. How can I refresh the form with latest data when I comeback from the datablock?
it's been awhile since I used Oracle forms but I believe you can deal with this by wrapping your update in a package. Then from the trigger that initiates the save create a Declare Begin Exception End block to catch the FRM-40654.
When this event is caught in the exception block try requerying then updating the information by calling the packaged procedure again.

Retry period after an unhandled exception in a Workflow

Currently in our workflow application if it encounters an unhandled exception it will reload the workflow from the most recently persisted state and try again. Are there any ways to configure how this works exactly? If a service is down for example the workflow will reload around every second and try to run again which when there are multiple workflows all doing the same thing can result in thousands of exceptions per minute.
I think that using the timeToPersist and timeToUnload properties on workflowIdle might have something to do with this. Currently we have this set to:
If I set timeToUnload to 1 minute will that mean the workflow will only be able to retry once every minute?
TimeToPersist and TimeToUnload won't come into play here- those values determine how long a workflow has to be idle before being persisted/unloaded.
You can probably use WorkflowApplication.OnUnhandledException to create a catch-all exception handler (assuming you're using this class to create workflows).
http://msdn.microsoft.com/en-us/library/system.activities.workflowapplication.onunhandledexception.aspx