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.