DConnector via BSSV connections to E1 and roll backs

johndanter

johndanter

Legendary Poster
Hi folks,

I have an odd issue in which 'some' database inserts appear to be rolled back when there is an error in a process called via a BSSV. I brought this up before (search DConnector)
However the same BSFN and data can be executed via a local call or through DC Links XML Connector even though the same error occurs and everything will be fine.

What I've done is is complete a few WOs using 2 systems. One via a DSI test (local call) and the same WO ITM and parts list using BSSV.
The BSSV method seems to rollback some of the data base inserts/updates whilst leaving others. The DSI method also throws the error but doesn't rollback anything

Does anyone know more about the DConnector, I can't find info, OR know of a way to make sure ALL database transactions are rolledback under the same DConnector SQL ID.

Inserts to F4111 for IMs, F41021 stock decrements and F4108 insert all seem to be gone but others remain in the BSSV version. Very odd.

This is an SQL from a BSSV call

dbsql_i.c175 - 42598520/515 WRK:GTSSVCUT_3123C388_DConnector INSERT INTO UTDTA.F4108 (IOLOTN, IOLDSC, IOLOTS, IOMCU, IOITM, IOLITM, IOAITM, IOVEND, IOKCOO, IODOCO, IODCTO, IORLOT, IOLOTP, IOLOTG, IOMMEJ, IOSERN, IOUA01, IOUA02, IOUA03, IOUA04, IOUA05, IOUA06, IOUB01, IOUB02, IOUB03, IOUB04, IOUB05, IOUB06, IOUSER, IOPID, IOUPMJ, IOTDAY, IOJOBN, IOLRP1, IOLRP2, IOLRP3, IOLRP4, IOLRP5, IOLRP6, IOLRP7, IOLRP8, IOLRP9, IOLRP0, IOLOT1, IOLOT2, IOLOT3, IOBBDJ, IOBODJ, IODLEJ, IOOHDJ, IOSBDJ, IOU1DJ, IOU2DJ, IOU3DJ, IOU4DJ, IOU5DJ, IOCHDF, IOWPDF, IODOC1, IOLOTR, IOLOTC) VALUES ('201710020002 ','71622-01 KIT, READER, FREESTYL',' ',' 245',5279186.000000,'5279186 ','5279186 ',161905.000000,' ',3059994.000000,'WO',' ',0.000000,'K ',120179,' ',0,0,0,117275,0,0,0.000000,0.000000,0.000000,4.000000,0.000000,0.000000,'009107','EP31114',117275,63649.000000,'GTSAX-JDED',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',117275,117275,117275,117275,117275,117275,117275,117275,117275,117275,' ',' ',3059994.000000,'0',' ')


This is an SQL from a local BSFN call

WRK:Starting jdeCallObject INSERT INTO UTDTA.F4108 (IOLOTN, IOLDSC, IOLOTS, IOMCU, IOITM, IOLITM, IOAITM, IOVEND, IOKCOO, IODOCO, IODCTO, IORLOT, IOLOTP, IOLOTG, IOMMEJ, IOSERN, IOUA01, IOUA02, IOUA03, IOUA04, IOUA05, IOUA06, IOUB01, IOUB02, IOUB03, IOUB04, IOUB05, IOUB06, IOUSER, IOPID, IOUPMJ, IOTDAY, IOJOBN, IOLRP1, IOLRP2, IOLRP3, IOLRP4, IOLRP5, IOLRP6, IOLRP7, IOLRP8, IOLRP9, IOLRP0, IOLOT1, IOLOT2, IOLOT3, IOBBDJ, IOBODJ, IODLEJ, IOOHDJ, IOSBDJ, IOU1DJ, IOU2DJ, IOU3DJ, IOU4DJ, IOU5DJ, IOCHDF, IOWPDF, IODOC1, IOLOTR, IOLOTC) VALUES ('201702100003','71622-01 KIT, READER, FREESTYL',' ',' 245',5279186.000000,'5279186 ','5279186 ',161905.000000,' ',3059980.000000,'WO',' ',0.000000,'K ',120179,' ',0,0,0,117275,0,0,0.000000,0.000000,0.000000,4.000000,0.000000,0.000000,'RR165972','EP31114',117275,44336.000000,'EUGTS-W7-D',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',' ',117275,117275,117275,117275,117275,117275,117275,117275,117275,117275,' ',' ',3059980.000000,'0',' ')

Thanks

John
 
Last edited:
I encountered a similar behaviour with the SalesOrder BSSV and found out that even though the SO MasterBSFNs are the final arbiter of business logic, JDE BSSVs call them via a different set of wrappers that have their own logic. Since I'm more familiar with the SalesOrder BSSV.

The commitSalesOrder is called after the SO MasterBSFNs have completed - with or without errors - as the very last step of the SO BSSV code. It attempts to commit the changes to the database and rolls back those changes if there are issues at the database level.

I would imagine that the same pattern have been applied to the other JDE BSSVs.

EDIT: I tried to attach a screenshot but it was too large. Hopefully did a better job this time.
 

Attachments

  • 2017-10-02_10-21-59.png
    2017-10-02_10-21-59.png
    7.4 KB · Views: 27
Last edited:
Hi

Thanks for you reply.
You are saying the rollback is inside the BSSV itself, yes?
That would make sense if ALL transactions were rolled back but it's not the case.

In my BSFN call it's WO Completiins. So F4108 F3111 F4111 F41021 etc, all wrapped up in the one call.
It seems to do some update but not others. All very odd. It's like some SQL is in a bubble and other SQL in another.

Not sure if that makes sense, but like it seems to have many transaction control 'bubbles' of SQL action.

I'd love to either wrap them all up in the same bubble or have no bubble. As it works via DSI
 
Yes, with SOs at least, the rollback is happening inside the BSSV.

I'm not familiar with WorkOrders. But if you've already figured out that using a call to the DSI BSFNs is the way to go, why not create a Published BSSV wrapper to call the DSI BSFNs?

We did something similar when we needed a PBSSV for the ShipConfirm process. We distilled the P4205 logic and how it calls the ShipConfirm BSFNs into 1 NER which we then nested inside PBSSV wrapper.
 
OK that makes sense. Probably the SO manager goes onto call several BSFNs inside the java? As it would have to right? It would have to call the Begin, Edit and End doc or one E1 BSFN that called all 3.

I wrote the BSSV java myself and I call my own BSFN (a clone of DSIs WO Completion) that goes onto call everything it needs. So I know the BSFN works.
This same BSFN is then called in DSI. It works locally for me using and via DSI just not through BSSV :) All very odd.

I can't see any commit/rollback in my Java.

I did find this but it still doesn't answer why 2/3rds get rolled back leaving the 1/3rd. All from ONE BSSV call. It's down to the Iconnection. I can change it to IConnection.MANUAL and then at the end do a commit.

https://docs.oracle.com/cd/E24705_01/doc.91/e24219/transaction_processing.htm#EOTME00124
 
Last edited:
Yes, the SO manager calls those Master BSFNs individually - using a new set of wrapper BSFNs instead of just 1 wrapper.

SO manager BSSV does the same as you're proposing, setting IConnection.MANUAL. That sets the transaction boundary and also makes it so that subsequent BSFN calls don't auto-commit their transactions.

After the code block to manually commit/rollback the SO document in the screenshot I posted, it executes a BSFN, TPPostCommit, that updates the WorkFlow stuff. So depending on whether a commit or rollback was done on the SO document itself, some stuff still gets done to act/record what was successful and/or what failed.

So if you want an all or nothing approach, set IConnection.MANUAL. But if you want each BSFN to do their thing, set IConnection.AUTO.

The other thing to be aware of, as indicated in the manual in section 9.2, is the behaviour of the startPublishedMethod, finishPublishedMethod, close PBSSV methods. They define the TP boundaries of the entire PBSSV; the large "bubble" that envelopes the smaller "bubbles".
 
John,
You can design BSSV using MANUAL commit but remember your function also should match that design. You might have to revamp the E1 function you use to perform all the updates. This is one of reason why JDE had to completely write new wrapper for Sales order.
You might also have to go thru the function and check the transaction boundaries in E1 code there are many places where JDE has some tables which are not in boundaries.

Do you see anything in logs specially the BSSV logs?. I suspect it can also be timeout issue?.

Thanks,
Chan
 
Well I've found the issue. By default the Iconnection in a BSSV is MANUAL. (When the connection mode parameter is not specified, the default connection mode is manual) So I need to change to AUTO to pass control back to the BSFNs when TP is on.
Sadly whats's happening for me is the 'error' doesn't actually prevent the transaction form occurring happily enough. So the COM and BSSV knows there is an error, the BSFNs know they are under MANUAL commit mode so await an instruction from the BSSV to commit the DB entries
So whats happening is right. It's a BSSV and if you encounter an error why would you want to commit the DB entries? It's actually a great thing, but ads we all know E1 spits out loads of warnings and errors but can still do a happy DB transaction. (as is the case here)

I did remember something about this (wrapping complex BSFNs in a BSSV) from years back but couldn't put it into words eloquently enough to warn my manager :) Plus it's kind of intuitive, if there's an error, roll it back. Issue is this is partial due to the master BSFNS having their own TP boundary

I'll make the java Iconnection.AUTO and let you know how I get on

So I'll be doing this:

In your manager change this bit
context = startPublishedMethod(context, "GetGTSWOCompletions", vo);
to
context = startPublishedMethod(context, "GetGTSWOCompletions", vo, IConnection.AUTO );
 
Last edited:
Final update:
This now works. Even though I get the 'acceptable' errors coming back via the COM (acceptable as in the process still goes ahead and works fine via DSI) ALL IMs, F3111, F4108 etc all are updated and committed.

Here's what I changed in my JP manager class

// BEGIN: John Danter 09/10/2017 MPRJ0082.57.04C MPO PACK BSSV Commit mode AUTO
// SR 3-15860622211 : BSSV DConnector rolling back SOME not ALL DB updates/inserts when error detected

// context = startPublishedMethod(context, "GetGTSWOCompletions", vo);
context = startPublishedMethod(context, "GetGTSWOCompletions", vo, IConnection.AUTO );
// John Danter - and add this to change connection
connection = context.getNewConnection(IConnection.AUTO);
// END: John Danter 09/10/2017 MPRJ0082.57.04C MPO PACK BSSV Commit mode AUTO
 
Back
Top