Externally calling a NER from outside of E1 - Non BSSV wrappeer options)

[RussellCodlin]

It kind of also depends on what you are calling and the design of your third pary application as to how you set these parameters. The re-use of the session ID is not only to avoid the overhead of creating a new session on every BSFN call but also to maintain state at the business logic level. For example we use XML call object for our point of sales system which involves calling some wrapper functions to the SOE MBF (F4211FSBeginDoc, F4211FSEditLine, etc.). We have to keep the session active to maintain state between the MBF calls (jdeCache state primarily), so we set the timeout to 29 minutes (1 min. less then our web session timeout - on web session timout we effectively call any cleanup BSFNs). When the sales order is complete we explictly terminate the JDE session with the XML call that Craig referenced.

Very true, you need the session to handle transactions. I will say we tend to avoid using this approach because there are number of ways thing can get ugly that are hard to deal with. Our usual recommendation, especially with functions that are executing from mobile clients, is to wrap transactions up into a single NER. This way the transaction is self contained and you don't have to worry about things like network failures or high latency causing you problems. Where a transaction has multiple lines we'll prep all of the data up in a work table first and then let the edit line loop through. You can write any errors on the edit line back to the work table and then respond with a general error state back to the client from the NER. Just makes things simpler and far more robust.

 

[Alex_Pastuhov]

Yes, XML. But it does not require JDE XML "Thin Client" DLL's and this means a lot of things:
1) We can do this in x64, or on Mac, Linux, etc. Even under Android & iOS ;-)
2) It is not subject to the handle & memory leaks of the standard JDE DLL's, which I believe are still there.
3) As we can now cache additional things & our comms are faster without those DLL's, it makes it the fastest interface into JDE in existence.
4) We manage sessions at all levels and that can be automatic or manually controlled.

In fact, we can ship this solution as a replacement "xmlinterop.dll" that offers the same interfaces as the standard one, but would not crash your client application, is faster and can be built for x64. But REST is probably the best option, easier to use in any case.

 

[craig_welton]

Yeah, we did the same thing with xmlinterop, wrote our own so we can live in 64bit land.

Craig