NER Asynchronous options

dpsflach

Member
I have a BSSV that is calling an NER, which calls other NERs. I know NERs call other NERs synchronously. One of the NERs called can take longer to run, which can sometimes cause the BSSV to timeout and do a rollback. What are my options to call this one NER asynchronously so it can return to the BSSV sooner and not get the timeout? I know one option is submit a UBE asynchronously that calls the NER. Any others?

Thank you.

E1 9.2.2.5
 
You can switch off the rollback commitment stuff. I had to do it here. You modify the BSSV connection call (context thingy that starts it all off)

Hate BSSVS! I'll dig it out and get back to you
 
Last edited:
The rollback of transactions is tied to the transaction mode (AUTO vs MANUAL commit) or if these are under TP (transaction processing).
For MANUAL commit you specify either the commit or rollback.
For AUTO commit there is NO rollback.
For all DB calls under TP (Transaction Processing), if a failure occurs, the system rolls back only the tables within this transaction processing boundary. If an insert/update happened outside the transaction processing boundary, the system does NOT rollback the record.

MANUAL commit:
The context object of a BSSV transaction is created with a MANUAL commit connection if in the corresponding published BSSV method, the startPublishedMethod is called with IConnection.MANUAL or if the startPublishedMethod is called without specifying the connection mode parameter at all.
For ex - context = startPublishedMethod(context, "addAddressBook", vo, IConnection.MANUAL);
(OR)
startPublishedMethod(context, "addAddressBook", vo); // so when the connection mode parameter is not specified, the default connection mode is MANUAL.

AUTO commit:
The context object of a BSSV transaction is created with an auto commit connection if in the corresponding published BSSV method, the startPublishedMethod is called with IConnection.AUTO
For ex - context = startPublishedMethod(context, "addAddressBook", vo, IConnection.AUTO);

With BSSV, the transaction is MANUAL by default if not otherwise specified.

It depends on each scenario and expected behavior to decide the commit node.
JDEDB_COMMIT_MANUAL, JDEDB_COMMIT_AUTO, Transaction Processing Boundaries and Deadlock ( Doc ID 1513147.1 )
Transaction, Transaction Processing, Commit and Rollback ( Doc ID 1208208.1 )
 
johndanter,

BSSV is somewhat new to me, but I can definitely see why you hate it. You just gave me another option for my issue. The auto or manual is not specified, which makes it manual. Which means it will either commit or rollback. I was able to re-create the timeout in test and from what I have seen in the logs it looks like all the processing was finished. But then it hit that timeout and did the rollback. So turning off the rollback in the BSSV might be the fix for my issue. Thanks for the information.

The NER that the BSSV calls is doing ship confirms, updating F4211, and inserting freight lines into F4211. From looking at the logs, the inserting of the freight lines is what is taking the most time in the NER and put it past the timeout. The reason the freight lines are taking so long is it is currently using the Master Business Function (B4200310) to insert these freight lines. To speed up the NER one option I have come up with is use F4211.Insert and call another business function to write to the Ledger instead of the Master Business Function. Just testing locally on my fat client to write 18 freight lines using the Master Business function took about 9 seconds. If I use F4211.Insert and call another business function to write to the ledger, it took under 1 second. But using F4211.Insert, I have to figure out how to populate all the fields in F4211 that the Master Business Function does.
 
johndanter,

To speed up the NER one option I have come up with is use F4211.Insert and call another business function to write to the Ledger instead of the Master Business Function.

I would strongly caution against doing that. I would profile the SOE MBF using debug logging and Performance Workbench or some other log analysis tool to figure were the performance issue is at and see if anything can be done to fix that. I would even try and fix the performance issue in the SOE MBF myself before I would insert records directly into the F4211 table.

If I understand correctly it sounds like the BSSV call to the BSFN is what is timing out, not the client consumer timing out calling the BSSV? If so, does someone know what controls the time limit for a BSSV->BSFN call? I have never ran into this issue so have never investigated. If there is a configuration setting or better yet something that can be set in BSSV code to extend the timeout period that might be the answer.

Just an FYI, it is possible to call a BSFN Async from another BSFN but I don't think that would help you in this situation.
 
Brian,

I understand the caution of doing an F4211.Insert. I've also always heard you never want to make changes to any of the Master Business Functions. Even If I wanted to modify the SOE MBF, I would not be allowed to. When my company upgraded from E1 8.0 to 9.2 we kept most all of E1 vanilla. We copied the vanilla programs to 55 programs if we needed custom modifications.

How do I call a BSFN Async from another BSFN? I know you can call a BSFN Async from an application.

Regards
 
I wasn't suggesting that modifying the MBF should be your first course of action... just saying by comparison it might be safer then trying to insert directly to the sales tables. And, its probably a moot point if your organization has a policy against it. You can still look to see where the performance bottleneck is. You might be able to add an index to a table for example. Maybe there is some weird blocking going on and then the stuff that John Danter suggested about TP might fix things... who knows. It would be good to know why it takes so long to add 18 freight lines.

As for the async BSFNs.
You can call a BSFN async from another BSFN using jdeCallObjectThreaded / jdeCallObjectThreadedJoin. But its not "fire and forget" like what you might be trying to do. You still have to retrieve the results so ultimately you would still be waiting for the BSFN to finish. Its more used for running multiple instances of a BSFN (or BSFNs) in multiple threads for performance. It has its uses and I have used it to speed a few things up but you have to be pretty careful where you use it. I don't think you want to run F4211FSEditLine in multiple threads on the same order... based on the testing I have done with jdeCallObjectThreaded I don't think F4211FSEditLine would be a good candidate to run in multiple threads.

I still think the real answer to your problem is setting the BSSV timeout when calling a BSFN... if that's possible... I have no idea if you can even do that, was hoping maybe some else here might know.
 
Thanks for the information Brian. I did ask about increasing the BSSV JDENET timeout from 90 seconds to 2 minutes. CNC said it probably would not hurt anything, but recommended we not do it. I think what we might do is make the whole interface asych by changing the BSSV to call a new NER that submits a UBE that runs the original NER.
 
johndanter,

BSSV is somewhat new to me, but I can definitely see why you hate it. You just gave me another option for my issue. The auto or manual is not specified, which makes it manual. Which means it will either commit or rollback. I was able to re-create the timeout in test and from what I have seen in the logs it looks like all the processing was finished. But then it hit that timeout and did the rollback. So turning off the rollback in the BSSV might be the fix for my issue. Thanks for the information.

The NER that the BSSV calls is doing ship confirms, updating F4211, and inserting freight lines into F4211. From looking at the logs, the inserting of the freight lines is what is taking the most time in the NER and put it past the timeout. The reason the freight lines are taking so long is it is currently using the Master Business Function (B4200310) to insert these freight lines. To speed up the NER one option I have come up with is use F4211.Insert and call another business function to write to the Ledger instead of the Master Business Function. Just testing locally on my fat client to write 18 freight lines using the Master Business function took about 9 seconds. If I use F4211.Insert and call another business function to write to the ledger, it took under 1 second. But using F4211.Insert, I have to figure out how to populate all the fields in F4211 that the Master Business Function does.

How does your NER read the qty for ship confirm lines?. Looks like the problem might be in the way your NER is designed. Also keep in mind that some of the JDE MBFs behave differently when called from BSSV. Its better to stick to Std MBFs for all updates else your NER would be in endless fixes.
 
Sorry for answering this so late. I just noticed your question. For the Ship Confirm the NER is call DSI's ship confirm NER (ND3N4205).
 
Back
Top