What’s the reasoning behind this?

So that the returned transaction ID can be accessed within the try and the catch blocks. If you do the startTransaction in the try, the returned ID will not be readily available in the catch block.

Thanks Rob… you’re a damn genius

I am not sure if I understood this. Can you guys elaborate with an example flow please.

So, you could call this pattern the “Try, Try Again” approach.

I assume you’re familiar with startTransaction and commitTransaction/rollbackTransaction services and how they are to be used.

If one structures the service this way:

SEQUENCE (exit on success)
–SEQUENCE (exit on failure)
----startTransaction (returns an ID)
----…
----commitTransaction (accepts ID as input)
–SEQUENCE (exit on done)
----rollbackTransaction (accepts ID as input)

In this case, the ID returned by startTransaction will not be at the “root” level of the pipeline, and rollbackTransaction will not do anything.

There are two approaches that can be used to address this.

1. If one calls getLastError, the ID can be retrieved from the pipeline var in the returned document. This is a relatively non-obvious solution but can be effective.

2. Restructure the service this way:

startTransaction (returns an ID)
SEQUENCE (exit on success)
–SEQUENCE (exit on failure)
----…
----commitTransaction (accepts ID as input)
–SEQUENCE (exit on done)
----rollbackTransaction (accepts ID as input)

In this case, the transaction ID will be in the “root” level of the pipeline and one does not need to get the ID out of the lastError structure.

just curious how long have u been involved with webMethods…

I started with Active Software stuff (what is now Broker Server) in '98. When wM acquired Active in 2000 I started working with B2B Server (now IS). Pretty much been doing this sort of work since then, with a 1 year hiatus when I worked an integration project that didn’t use wM products.

the catch block will be executed if any exception occurs in try block. in this case if we start the tx in try block and an exception occurs, the tx id will still be available in catch block(anyway the pipeline data will be carried to catch block).
what the use of starting the tx outside the try catch block?

Not so. In Developer it looks like the pipeline is intact in the catch block but at run-time it is not. Give it a shot with this simple example:

1. SEQUENCE (exit on SUCCESS)
1.1 SEQUENCE (exit on FAILURE)
1.1.1 MAP (set aVar to some value)
1.1.2 EXIT '$parent' and signal failure
1.2 SEQUENCE (exit on DONE)
1.2.1 BRANCH on '/aVar'
1.2.1.1 /[^ ]/ MAP (set bVar to some value)
1.2.1.2 $default: MAP (set cVar to some value)

When run, only cVar will be shown in the results pane.

I have two questions from this.

1. If i am not wrong the signal failure(exit flow or exit parent) step, causes the control to return to catch block and execute the statements under catch block?!!!

2. That means the pipeline variable values in try block are not accesseble in catch block.
   But i found assigning the variables of try block to variables in catch block!!.
   for eg: after the getLastError, to publish an Exception, the variables of try block are assigned to variables of some service in catch block that publishes the exception!.

1. Correct. The exit step was in the example to simulate an exception such as one might get when calling a DB adapter service. Control does indeed pass to the catch block and the steps there are executed.

2. The variables created in the try block will not be directly accessible in the catch block. One can do assignments with no problem but if those assignments use a source variable that was created in the try block, the target variable will not get a value at run-time.

Is there a specific code example that you’re wondering about?

That one way of doing it. I like the StartTransaction in my Try, since it goes to my catch, if error, and gives me nice little email or something.

I usually use a MAP step after getLastError to restore pipelines.

SEQUENCE (exit on success)
–SEQUENCE (exit on failure)
----startTransaction (returns an ID)
----…
----commitTransaction (accepts ID as input)
–SEQUENCE (exit on done)
getLastError (map error pipeline to Doctype say “myPipeline”)
MAP (map any fields you want to restore to “myPipeline”)
----rollbackTransaction (accepts ID as input)

This should work as well…

That’s correct. This is the approach I mentioned earlier: “1) If one calls getLastError, the ID can be retrieved from the pipeline var in the returned document. This is a relatively non-obvious solution but can be effective.” . Thanks to Rocky for posting the example.

my doubt is not cleared regarding accessing the pipeline vars in catch block.

For eg:
SEQUENCE(exit on success)
–SEQUENCE(exit on failure)
-----MAP(get currentDateTime and assign that value to txId variable)
-----startTransaction(assign txId to transactionName var of startTransactionInput)
-----commitTransaction(assign transactionName var of startTransactionOutput to transactionName var of commitTransactionInput)
–SEQUENCE(exit on done)
—getLatError
—rollbackTransaction(assign transactionName var of startTransactionOutput to transactionName var of rollbackTranscationInput)

Now my doubt is : Even if we created a txId var and assigned it to transactionName var of startTransaction service, when an exception occurs, the transaction(transactionName assigned to rollbackTransaction) is rollbacked.In this case we are still using the var of try block in catch block assignments!!

Can you post screen shots of your getLastError and rollbackTransaction calls?

Given what you described, the transaction may appear in Developer to be rolled back but at runtime it isn’t because startTransaction (and its field, transactionName) won’t exist at the root level in the pipeline. In other words, your catch block may not be working the way you expect.

Here are the screen shots:

1. startTransaction in try block. transactionName is the currentDateString
   
   

2. rollbackTransaction in catch block.

You’re going to need to upload the jpg file using the attachment facilities of the forum. Click the “Go Advanced” button below and attach your screen shots.

Sorry , i was unable to send the screen shots properly in my last post.
i am sending as a zip file
hope i did better now!

The screenshots don’t show everything, so I can’t tell if the service is mapping the startTransactionOutput record from the lastError/pipeline. If it is, then the catch block will function as you are expecting. If you are not mapping startTransactionOutput from the lastError/pipeline document, then the call to rollbackTransaction is doing nothing because rollbackTransactionInput/transactionName will be null.

Attached are the screen shots for getLastError and rollbackTransaction.

Is this the right way to rollback a transaction in catch block if we start the Tx in try block?

The screen shots are missing.

Hi,

I am starting the Tx in try block and committing in the same block.
FYI, the currentDateString is the transcationName.
I am rollbacking the Tx after invoking the getLastError service.

I am attaching the screenshots that involves :

1. getLastError pipeline
2. rollbackTransaction

Can you please confirm whether i am following the right procedure in rollbacking the transaction.

Many thanks
screenshots.zip (85.5 KB)

Almost right. Instead of this:

pipeline
…transactionName

The mapping from the source var needs to be:

pipeline
…startTransactionOutput
…transactionName

Thanks Rob

ok guys ,tell me one thing lets say i write the service as below
MAIN
TRY
Start transaction ( set the transaction name = hello)
----
----
—
Commit transaction( set the transaction name =hello)
CATCH
getlasterror
Rollback Transaction ( set the transaction name = hello)

i guess this should work …becouse all the transaction names are set values(hardcoded).
–sri

And the best practice is alwyas put the start transaction outside the try block …its better u kick off the service with start transaction and continue…
But the above procedure should still work

-sri

I believe that would only work in a single threaded environment. If you call the service from a couple of threads, your transactions will become confused.

I don’t know if this qualifies as “best practice.” Either approach, startTransaction outside or inside the try block, is workable.

Correct me if I am wrong…I think startTransaction inside try block should be a better option as this gives us the ability to start the transaction at a later stage so as to keep the transaction time minimum with the DB instead of opening it up before Try block and having the transaction open for longer time…Keeping it inside TRY block will help us achieve transaction with DB in a least time.

Thanks,
Puneet Verma

Are you saying that this structure:

startTransaction
SEQUENCE (exit on success)
…SEQUENCE (exit on failure)
…(call an adapter service)
…(call an adapter service)
…endTransaction (commit)
…SEQUENCE (exit on done)
…getLastError
…endTransaction (rollback)

is slower than this structure?

SEQUENCE (exit on success)
…SEQUENCE (exit on failure)
…startTransaction
…(call an adapter service)
…endTransaction (commit)
…SEQUENCE (exit on done)
…getLastError
…endTransaction (rollback)

What makes you say that? I agree that steps within the start and end should be minimized, but I don’t believe the SEQUENCE blocks add any execution time. However, I’ve never measured so I’m not 100% certain.

No…In the structure you mentioned there might not be comparable difference.But consider these structures…

Case 1:
startTransaction
SEQUENCE (exit on success)
…SEQUENCE (exit on failure)
…(map data)
…(some other logic step)
…(call an adapter service)
…endTransaction (commit)
…SEQUENCE (exit on done)
…getLastError
…endTransaction (rollback)

Case 2:

SEQUENCE (exit on success)
…SEQUENCE (exit on failure)
…(map data)
…(some other logic step)
…startTransaction
…(call an adapter service)
…endTransaction (commit)
…SEQUENCE (exit on done)
…getLastError
…endTransaction (rollback)

In this scenario , Case 2 would be a better approach to have the startTransaction just before we do any DB operation instead of Case 1 where the startTransaction is before Try block and we keep the Transaction with DB open for unnecessarily longer time when the same can be achieved using Case 2 in a better and more efficient way.

Thanks,
Puneet Verma

Thanks for the clarification. Your first post implied that simply moving the startTransaction step outside of the try/catch block would improve things. It didn’t mention any non-adapter service steps between the start and end.

I agree that between startTransaction and endTransaction, the number of steps should be kept to a minimum. Ideally, the only step(s) would be adapter services.

When an exception occurs, the pipeline rolls back to the state it was in before the “try” block (This can be pesky to debug). Putting the startTransaction before the try block ensures that if there is an exception, the transaction information isn’t wiped out of the pipeline.

I missed something here… which situation will only work in a single threaded environment?

Thanks!

This can be considered as best practice to all this discussion of where to put the startTransaction and how to retrieve the “transactionName” value in the catch block!!

write a generic svc which returns “unique_id” as the output… search on wmusers to get an idea on how to implement it… call this “generateRefID” svc

-----generateRefID (assign the value to transactionRefID variable)
SEQUENCE(exit on success)
–SEQUENCE(exit on failure)
-----startTransaction(assign transactionRefID to transactionName var of startTransactionInput)
-----commitTransaction(assign transactionRefID var to transactionName var of commitTransactionInput)
–SEQUENCE(exit on done)
—getLatError
—rollbackTransaction(assign transactionRefID var to transactionName var of rollbackTranscationInput)

I hope this should end most of the discussion on this topic!!

when you hard code the transactionName to something static like “hello” !!

Hi Saurab,
What you suggest will work just fine. We follow a transaction management best practice as below which does not require to create a unigueID. This is already handled by the stratTransaction service. WM BIS guide says this with respect to startTransactionInput / transactionName- “Specifies the name of the transaction to be started. If you leave this parameter blank, Integration Server will generate a name for you. In most implementations it is not necessary to provide your own transaction name”

1. Always use “startTransaction” service outside TRY/CATCH block, “commitTransaction” service inside TRY block and “rollbackTransaction” in the CATCH block.
   2. Do not explicitly set “transactionName” property for start transaction service. It is an optional parameter. Instead use the “startTransactionOutput/transactionName” variable returned by “startTransaction” service. Use this transactionName to commit/rollback the transaction.
   3. You may explicitly set transactionName when the service is serialized but it is not required.
   4. When dealing with nested transactions involving distributed transaction support, give additional care while developing your integration logic. In this case do not explicitly set the transaction name property. Instead use the “startTransactionOutput/transactionName” variable returned by “startTransaction” service for the appropriate levels of transaction and allow system to handle it.
   By calling the startTransaction inside TRY sequence we have to explicitly map it back from the pipeline and pass it to tollbackTransaction service. As IS rollsback the pipeline to the beign of TRY sequence in case of a failure it gives the CATCH sequence to access the transactionName straightaway.
   cheers,
   Sampath

I dunno if this qualifies as “best practice.” It’s just one way to do things. (I’m not a big fan of “best practice”–it has become an overloaded term that seems to have lost meaning, much the way “canonical” is meaninglessly bandied about.)

This is unnecessary. A call to startTransaction with a null transactionName will generate one for you. No need to reinvent a way to create an ID.

I had thought the discussion was pretty much over when the two approaches had been posted by the 6th post in this thread! But now we’re on the 4th page of posts. Perhaps there is enough info now.

Thread closed. Topic beat to death (and then some).