E9.2 ND3N BSFN use via REST / Orchestrations

[JohnDanter2]

Hi all

Does anyone know the implications of 'using' ND3N' type BSFNs in a company but calling them yourself via REST and not via MEPs platfrom?
I want to write either an android based or .NET mobile app to call into E1 to do various functions (Complete WOs, Ship confirm etc) and it appears the ND3N BSFNs are the perfect tools for the job as they have already wrapped up the Begin Edit and End Doc E1 BSFNs for me in one callable object.

Do you need to pay DSI MEP for the privilidge of 'using' these BSFNs or do they only charge you for the platfrom they provide that enables you to call them in your E1 system?

i.e. can you write your own wrapper to call them free of charge if they are on your system

Thanks

John

 

[alfredorz]

Hi John,
I don't know DSI MEP platform, but you can expose bsfn directly in orchestrator as rest service in tools release 23 or you could create a orchestrator and add your bsfn and publish the orchestrator as rest service.
Regards.

 

[JohnDanter2]

Hi John,
I don't know DSI MEP platform, but you can expose bsfn directly in orchestrator as rest service in tools release 23 or you could create a orchestrator and add your bsfn and publish the orchestrator as rest service.
Regards.

Hi

This is what I will be doing yes My issue is, what do you pay DSI MEP for. Their own wrappers to call the code or the BSFNs they call (which they wrote) and thwe wrappers.
As if I wrap them myself in an Orch I am still using thier BSFNS at the end of the day.

Tricky part is all the ND3N BSFNS come out of the box in 9.0 whether you use them or not. In 9.2 it is different, you have to get an ESU from them first

 

[jolly]

No issue as long as you are a licenced DSI customer. Legacy/deprecated DSI BSFNs used to live in the default JDE source code up until 9.2 when they were finally removed so from 9.2 onwards you won't have them unless the DSI ASU has been applied.

 

[JohnDanter2]

No issue as long as you are a licenced DSI customer. Legacy/deprecated DSI BSFNs used to live in the default JDE source code up until 9.2 when they were finally removed so from 9.2 onwards you won't have them unless the DSI ASU has been applied.

Hi, yes we have them installed in 9.2 and we are licenced. My question is more about moving away from them and still using them using our own calling APIs not theirs
As in I've written one or two of my own REST APIs to manipulate their outputs to better suit some of our consumers, so I am not sure if a licence still applies in this case.
As I wrote the calling API not them....but they did write the ND3N (which we got for free in 9.0 - so it's confusing)

 

[eydeak]

The ND3N functions are copyrighted by DSI and legally you need a valid DSI license to use them. I'm not sure how the enforce the license.

 

[Patrick]

Yeah they started, with 9.1, only delivering them if you are a licensed customer. It used to just be part of JDE/E1 before that as you mentioned. As long as you are paying for licensing and support you can use them as you would like. If you leave DSI, just to be on the safe side, you should probably write similar functions to the ND3Ns as custom objects to keep yourself compliant, but I've never heard of DSI coming in and doing an audit of pervious clients still using their functions. It'd be pretty outrageous if they started

 

[JohnDanter2]

Cheers both

What I've started doing is replacing ND3N4617 with a SREQ over P4617 for example. Some ND3N are referencing E1 screens so a SREQ called via Orchestration/REST is going to replace them.
Sadly the error messages from an SREQ are not as informative as those from NERs. So I may end up writing my own wrapping NER to mimick the ND3Ns.
All r&d atm