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

johndanter

johndanter

Legendary Poster
Hi gents,

I've written a NER in E1 that my .NET team would now like to call.
Now I know I could write a BSSV wrapper to allow them to do this, but I'm a little snowed under at the moment. So I'm exploring my options.

What other options do I have to allow them to call this NER from .NET?

XML Call object could be an option? But I've no idea how to direct them.

We are on 9.0 and in DV have TR 9.1.5.3 (9.1.0.3 in PY, UT and PD at the moment)

Thanks

John
 
Last edited:
Here is my NERs DSTR

Data Structure: D570096A - GTS OVE Reset DSTR (IN)
BF szDocumentTypeSOPOWO_DCT [DCT] (IN)
BF mnDocumentOrder_DOCO [DOCO] (IN)
BF szOrderType_DCTO [DCTO] (IN)
BF szCompanyKeyOrderNo_KCOO [KCOO] (IN)
BF mnLineNumber_LNID [LNID] (IN)
BF mnShipmentNumber_SHPN [SHPN] (IN)
BF cErrorCode_ERRC [ERRC] (OUT)
BF szErrorMessage_DTAI [DTAI] (OUT)
BF szDescriptionAlpha_DSCA [DSCA] (OUT)
BF szSourceResultField_RESU [RESU] (OUT)
 
One question...

What type of connector is this using to talk to E1?
Might be a silly question, but is it an XML connector?

The reason I ask, is I believe that the XML connector fires a sticky connection to E1 that is hard to bleed off the server.

So would this XML Interop do the same thing and result in a sticky connection to E1?
 
Yes, this uses standard xml interop.

I don't know what you mean by a "sticky connection".
 
The XML connection will create a session ID and return it upon first call. You re-use that session ID on subsequent calls so you don't have to re-authenticate. I'm pretty sure you can send an endSession method to release resources when done.

Craig
 
There you go. That's what I was getting at above.

Craig has explained it far more eloquently than myself :)

In my eyes, a sticky connection is a connection request into E1 that stays open after the action/request to connect has been executed.

I only know about them from DSI bar code software that stays connected all day. It's because the bar code device uses the same session for speed I guess.
Draw back is you need to boot them off the E1 system when you need a free E1 system.
 
E1: XML: XML Interoperability. How to User the 'session' and 'sessionIdle' Attributes (Doc ID 627601.1)
 
There you go. That's what I was getting at above.

Craig has explained it far more eloquently than myself :)

In my eyes, a sticky connection is a connection request into E1 that stays open after the action/request to connect has been executed.

I only know about them from DSI bar code software that stays connected all day. It's because the bar code device uses the same session for speed I guess.
Draw back is you need to boot them off the E1 system when you need a free E1 system.

You set the stickiness of the session as a parameter of the XML call and as mentioned reuse of the session id. We generally recommend our customers set the timeout to 180 seconds as this ensures that you don't have the overhead of creating new sessions on each call but at the same time you're releasing resources in a timely fashion on the enterprise server. Of course, if you are dealing directly with the XML dispatch kernel then you need to handle session timeouts and retries on your client side code. Just be aware that the session id is only used for BSFN/NER calls and not for lists or ube's as JDE handles the session stickiness for these internally.

Also be aware if you are recycling your call object kernels that you need to deal with it as the XML Dispatch kernel doesn't get recycled so it can throw some weird errors. We also see this with running UBE's through the XML interface with regards to the security kernel being recycled whilst you're trying to submit. Worst case scenario is the dispatch kernel times out which by default takes 10 minutes.
 
Cheers Russell.

If I get the thumbs up to go the XML connector route I'll be sure to pass this on. the issue we have is with DSI barcode software. We have no control over their software calls into E1. So I guess that's something they need to sort out.

I think I'm going down the BSSV path to expose this NER after all this :(
 
Cheers Russell.

If I get the thumbs up to go the XML connector route I'll be sure to pass this on. the issue we have is with DSI barcode software. We have no control over their software calls into E1. So I guess that's something they need to sort out.

I think I'm going down the BSSV path to expose this NER after all this :(

Each unique connection to the XML Dispatch Kernel gets its own session and the session timeout is defined in the first call. This means that the DSI server will have its own session and should not be a factor unless you're trying to use the DSI server to expose the service.

You may want to consider having a look at our integration solution if you're going down this path as it is designed specifically for the type of thing you're doing and is far simpler than developing and deploying BSSVs. http://www.rinami.com/products/cantara/platform
 
... the issue we have is with DSI barcode software. We have no control over their software calls into E1 ...

Just curious what you guys are trying to accomplish there. I assume, based on your previous reference to your .NET team, that they're creating a custom API for use in DSI scripts... is that correct?

If this is true, I guess I question why the need to call into E1 from the custom API. What is the purpose of the custom API? I would think whatever the purpose of the API, it could return control to the script to perform any/all E1 interaction.

If this is not for a custom API, then DSI software already provides the mechanism to call E1 BSFN's.
 
You set the stickiness of the session as a parameter of the XML call and as mentioned reuse of the session id. We generally recommend our customers set the timeout to 180 seconds as this ensures that you don't have the overhead of creating new sessions on each call but at the same time you're releasing resources in a timely fashion on the enterprise server.

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.
 
Russell, Alex: Do your solutions use XML Interop or some other way to call business functions in E1?
 
Russell, Alex: Do your solutions use XML Interop or some other way to call business functions in E1?

Our solution uses XML Interop. In that way we do not require any particular O/S combination or software agents installed on the enterprise servers. Users just use our web admin console to create service definitions, whether those services are business functions/NERs, queries against tables and business views or submitting reports. Those service definitions are exposed through REST and can be called using either XML or JSON. We also include role security for the services so that the ability to call the services, including business function calls, is controlled by JDE role.
 
Just curious what you guys are trying to accomplish there. I assume, based on your previous reference to your .NET team, that they're creating a custom API for use in DSI scripts... is that correct?

Hi Jeremy,

No mate. No custom API or calls/changes to DSI at all. I was merely commenting on the fact DSI suffers from sticky connections.
We do use DSI to call JDE BSFNs in our scripts yes in the barcode scanners, but this wasn't the issue here.

I was asking about ways of calling BSFNs from outside. This is a totally separate platform to our DSI stuff.
 
Back
Top