E9.2 Orchestrator - database connection method & transaction processing

[JohnDanter2]

Hi all

Forgive the rambling here, but a few years back I noticed we had a commitment issue with a .NET program we wrote to connect to E1 as we chose to connect using BSSV and it connects and uses DConnecter in all it's database transactions. Any errors would then rollback the updates/inserts. TR 9.1.5.3

Understanding Transaction Processing

The fix was to change the connection from Auto Commit to Manual Commit in the BSSV java. Oracle do not support this.

So in 9.2, I plan to connect to E1 BSFNS via the Orchestrator etc, but I am struggling to see how this may affect the DB events.

Does anyone know if this issue still exists in 9.2 and the orchestrator?

Thanks

John

 

[LarsJorgensen]

Hi John,

did you find an answer to your question?

I think I am facing the same issue. I would like to call a set of BSFNs that do table i/o from Orchestrator Studio but I cannot see how the called BSFNs can be included in the same transaction. The result should be that if one BSFN call fails then the DB transactions from the previous BSFN call should be rolled back.

Any feedback would be highly appreciated

Kind Regards,

Lars Jorgensen

 

[Gustavo Barizon]

Guys,

Orchestrator isn't the E1 DEV environment.

Even though you have the ability to call BSFNs in ORCH, things like cache, transaction control, will be extremely difficult to handle.

My suggestion is to wait for BSFN via LEX - then I think that will be in a lower level and then we can think about it.

Remember, Orchestrator runs on AIS Server, under a XML file to process calls to JAS. There's a lot of overhead in the process and a lot of things can happen in between with multiple users making multiple calls, with multiple records, with multiple rollbacks.

I've never had a case for rollback of transactions, but if I'd have such requirements, then I could try to make some extra controls and flags and then make this type of routine manually depending on the case, of course.

My 2 cents. I hope this helps.

- Gustavo

 

[JohnDanter2]

Hey Lars

Not yet no but I will play about soon

Hang on...Lars, is that you? Jason Murphy's friend, right?

 

[JohnDanter2]

Guys,

Orchestrator isn't the E1 DEV environment.

Even though you have the ability to call BSFNs in ORCH, things like cache, transaction control, will be extremely difficult to handle.

My suggestion is to wait for BSFN via LEX - then I think that will be in a lower level and then we can think about it.

Remember, Orchestrator runs on AIS Server, under a XML file to process calls to JAS. There's a lot of overhead in the process and a lot of things can happen in between with multiple users making multiple calls, with multiple records, with multiple rollbacks.

I've never had a case for rollback of transactions, but if I'd have such requirements, then I could try to make some extra controls and flags and then make this type of routine manually depending on the case, of course.

My 2 cents. I hope this helps.

- Gustavo

Hi Gustavo

I think you missed my point. I do not want to roillback the transactions. I am saying BSSVs do this when it detects an error. I am hoping AIS REST does NOT rollback when it to detects an error.

That is my question, does AIS rollback like BSSV does by using DConnector

Thanks

John

 

[Stank1964]

As suggested in this thread, calling BSFN can be complex. Orchestrator is not a good mechanism to use when calling BSFN gets complex.

But.... If you build a BSFN that does whatever it is you need it to do in all of it's complexities, simply have Orchestrator call it. Replace the BSSV in your situation with a new BSFN.

 

[BOster]

As suggested in this thread, calling BSFN can be complex. Orchestrator is not a good mechanism to use when calling BSFN gets complex.

But.... If you build a BSFN that does whatever it is you need it to do in all of it's complexities, simply have Orchestrator call it. Replace the BSSV in your situation with a new BSFN.

This is the method I have used with both BSSV and Orchestrator. Create a "wrapper" BSFN that is purpose built to be used as an interop interface and then BSSV or Orchestrator simply becomes a thin Web Service (SOAP, REST) wrapper.