eCommerce Development/Integration

[Shayne Judkins]

I have been tasked with designing a Web application that will allow online ordering for some limited (parts only) items. (This will eventually go to the point where we are offering our full line of products for sale online.) We use JDE version Xe (Windows) with MS SQL Server as our db.

Based on my limited research, it looks like the EDI interface is one way to accomplish this. We have tested populating the tables: F47012 and F47011 and running the R47011 program and this seems like it will work for us. (It processes the order and creates a Sales Order successfully.)

Do you guys have any thoughts or opinions on this? Is there a better solution for "eCommerce". My concern with using this interface is the only way I can figure out how to run the JDE program (R47011) is via the scheduler. I would much rather have a SQL stored procedure or something like that where I can better automate the process.

The other two options I see are purchasing something like "IT4Profit" or "Lansa", but we already have similar functionality on our web site (Inventory lookup, order status, etc.) and it seems like overkill.

The final option I see is to write the Stored Procedures to actually process the Orders ourselves by exacuting the proper business rules and validation on the incoming orders and inserting them straight into the Sales Order Header and Detail tables. I think this is do-able (we have several programmers on staff that are very familiar with the JDE schema), but I am worried about duplicating the business rules via these custom porcesses (and more importantly, leaving some important business rule/validation out of the process).

Any input is appreciated!
Shayne

 

[78aspide78]

H Shayne,
just some consideration;
EDI is a robust solustion, you can use runube command line to fire the report at the end of table fill.

If you need to perform some kind of logic or you need to interact with jde a torder entry time (for example to obtain the price or the availability of the item) you can use com interface or java connector or xml call object to call the sales order mbf but you need to spend more time to develop the integration.

I hope it was useful.

Regards.

Bruno Condemi

 

[Shayne Judkins]

Thanks for your feedback.

Maybe I should explain our topology a little better, just to be sure there isn't a better solution out there. I am looking for POSITIVE or NEGATIVE feedback on the way we are doing things and a recommendation on the route to take for our eCommerce (online ordering) solution. I am realatively new to JDE and I am not sure if the processes the previous programmers used are "best practice" or if there is a more preferred method for integrating with JDE.

One of the features of our Web Site is a customer portal. This portal provides our customers with information (from our JDE data), such as "Real-Time Inventory", "Invoices" (printing only), "Reporting" and "Sales Order Lookup" (Status/printing only). This information is retrieved from a jde database in our DMZ. This database is replicated FROM our production database on our LAN. Therefore, it is a "read-only" database.

Now, we are looking into allowing our Customers to actually place orders on this portal.

How would you guys tackle this problem? Would you use the EDI integration? I have also considered getting something like K-Rise EASYProcess or EASYConnect. (Although, we are already doing most of the functionality they provide by writing SQL statements and stored procedures that just access the tables directly. It seems like overkill to now go through a "SDK" or other framework.) Of course, we could just put the orders right in the Order tables, but I see many problems with that such as: No Audit Trail, What about Validating the data? and all the other "business rules" that get applied to the order before it hits he order tables (such as removing it from inventory?? etc)

Obviously, whatever we decide to do, we will need a process on our LAN that monitors the DMZ server to look for these orders and then brings them in, processes them and returns some sort of status to the DMZ Server. (A product like the K-Rise framework would probably eliminate the need for a replicated database...and still fit withinin our security framework...but our processes would have to be re-written to their framework/sdk. That isn't a HUGE problem, but it is a consideration.)

Keep in mind we don't have any actual JDE programmers on staff. We use a company to provide those services (and we could use them for this if we need their services). Our staff is limited to T-SQL, Crystal Reports and DOT Net programmers.

We are running:

JDE PeopleSoft EnterpriseOne Xe (Version 7333, SP 23) -Windows 2003 (cluster)
MS SQL Server 2003 (The DBs are still in 2000 compatibility mode.)

 

[JMast]

Shayne,

I would strongly recommend that you seriously consider looking at some of the e-Commerce packages that have prebuilt architectures to run JDE and other ERPs.

It is very tempting to just expand on what is currently in place. Sometimes that is the best way to go, but make sure the fact that it seems cheaper and less hassle now not be the driving force.

I don't know the details of your business (# of SKUs, customer complexity, ...) but here are some general considerations:

1. It sounds like the complexity, volume... of transactions are going to significantly increase. A prebuilt package will have been tested (ask for references) in environments that are similar to where you will eventually be. Provides confidence now that future growth will be supported smoothly.

2. JDE XE is very old. 2013 is coming quickly. What happens if the decision is made to scrap JDE and go with another ERP entirely? Even an upgrade to 9.? will likely be significantly different. A prepackaged system will have been updated or rebuilt to handle 9.?. Many of them also have interfaces to other ERPs as well.

3. SQL 2003 (really 2000 since you are in compatibility mode) is built on older architecture and features some of which disappear in 2008. When you upgrade your DB, all your stored procedures must be reviewed and tested. What happens if you decide to move to Oracle DB? Again, a packaged system vendor will have built and tested the newer databases. Suddenly, your extensive review, coding and testing becomes a much simpler upgrade and essential testing.

4. You are also at the mercy of the quality of the JDE programmers over the years. Each time you need to upgrade the architecture, or add features to the interface, a different programmer may be involved. The programmer will have to study and understand what was previously done. Also, they may not be as skilled leaving your system open to inefficient code.

The downside, of course, can be maintenance fees and breaking through the culture of why throw out what has worked in the past.

My opinion, if the present and future dollars make sense, is you are trading rework right now to install a package with continued rework and testing each time the architecture changes in the future.

Jer

 

[JMast]

Should have clarified -- I am talking more along the lines of packages like ERP2WEB which are fully built web storefront architectures that you integrate into your website as opposed to using EASYProcess to develop your own integration.

 

[Shayne Judkins]

It seems like EASYProcess would at least cover most of the points you make (but not all of them). I mean, I dont see us ever switching to Oracle as a Server or moving aways from JDE. The company has been pretty much staked on these two technologies. The cost of EASYProcess is very much in line with something we can afford (and even moreso with it's sibling "EASYConnect"). The also offer us a 30 day trial (could be true with other software) in order for us to "prove out" our application.

(With that being said, I have been in IT professionally for over 20 years and I know it is naieve to say "this will never happen", but I DO feel as confident about that statement as I possibly can.)