Internet and Navision Financials?

Andreas_Lundin

Hi all

This is just a comment on the increasing use of integrating Navision with the Internet. It seems like everyone is using the Microsoft approach when developing Internet integration. The solution normally requires MS internet software, SQL server,
MS ASP(Active Server Pages).

Does anyone use other solutions than the ones using ASP, and what are your experiences? In my opinion it is possible to make a solution based on other products.

I am developing a sample solution due to the price of an ASP solution, just to see the if it is an worthy alternative. And so far I think it is. It is possible for you to minimize your expenses when tailoring a Navision-to-Web solution. My solution is using the following components:

A server functioning as an Internet server with the following software and technical:

- Navision Financials and C/FRONT
- Perl 5.01 with C-extensions to integrate with C/FRONT to handle CGI-scripts between Server and Navision
- Internet server software(minimal)

That's just about what is required to make a fairly good solution. The beauty of it is that it's is cheap. It doesn't require all these expensive MS products to work. So the work-flow on a solution like this would be, if you think of it as a employee making a search on the company server from their home computer.

1. A HTML-file contains a form for the employee to fill out, with search criterias etc.

2. The HTML-file contains a cgi(Common Gateway interface) call to the company server, where the Perl interpreter takes the search criterias, connects to the Navision server using C/FRONT. The C/FRONT extension part of Perl returns the search result, and Perl generates a new HTML page on the server containing searh result. And finally the employee is directed automatically to this newly created page.

Perl is a free product under the GNU-license. It' orginally developed for the UNIX community, but have been ported to Windows, and it can run on Windows95/98/NT/2000.

So this could be an alternative to your ASP solutions. Any comments are welcome.

Regards
Andreas

Luc_VanDyck

The main problem I see when using ASP and C/FRONT or ODBC is that every web-user counts as a user when connecting to your Navision database. So if you have 10 web-users simultaniously on your site, you will need 10 user-sessions in your Navision license file.

Navision Web Shop uses Microsoft Message Queue to establish a permanent connection to the database. So you always use 1 user, regardless of the number of web-users.

Andreas_Lundin

Hi again

Just a comment on the amount of users for your license file <img border="0" title="" alt="" src="images/smiles/icon_smile.gif" />
Yes, it's correct that 10 simultanious user will require a 10 user license.

But I see another scenario in order to handle this. The users are only connected to Navision when updating their data into Navision. Any data collection is handles prior to the update. Meaning that the data to update is done in just one go, and that shouldn't take that much server time. Also data requests is done in one go.

I would estimate that you could reduce the number of users required in the solution by making af data buffer zone handled by the a Perl routine.

The Perl/CGI solution is of course not the choice to be for a grand scale webshop solution with hopefully thousands of simultanious customers. But it is a good alternative when speaking of corporate solutions.

You should of course also consider the price. If a customer only wants a solution for internal use(administration, logistics, economics etc.). Why should he or she buy a solution meant for E-commerce, when they could use a cheaper and a just as good alternative?

Just some comments to consider <img border="0" title="" alt="" src="images/smiles/icon_smile.gif" />

Regards
Andreas

db

I don't think that using C/Front you must have session per connection.
I was developed replication program that uses one session for replicating all connections. This helps avoid locking connections. If you think about direct connection to NF using CF it is useless. You need to make own exchange protocol over TCP or UDP. We writed program that not use NF embeded communication over TCP, we maded own streeming communication.
Then we writed this program we thinked about web too.
There maded requesting methood. In web solution it can be look like:
on server runing soft sending data request (there sorting, filters, table & field lists are available);
on NF server runing prog. starts sending to request sender all requested data.
on NF server C/AL can be run too. (using tempory tables).

Using this method on web solution, problem is data colision tracing. All data pushed over one connection & difficult to track data expiration.

............................................................
Cfront for Unix ?
it is available ?

How many WebShop cost including needed soft ?

Then Bill die NF will die too ? <img border="0" title="" alt="" src="images/smiles/icon_smile.gif" /> <img border="0" title="" alt="" src="images/smiles/icon_smile.gif" /> <img border="0" title="" alt="" src="images/smiles/icon_smile.gif" />

Andy_Sandefer

Greetings,

I work as a developer for Integrated Systems Group, a Navision Solution Center located in Indianapolis, IN. I agree with your statement that a non-Microsoft e-Commerce solution should be developed for Navision. Our company has done just! Please visit our website for more information! http://www.isgcorp.com



[This message has been edited by Andy Sandefer (edited 07-04-2000).]

ohlfsen

Have you been looking at PHP.

Heard somewhere that this should be a worthy alternative to ASP.

<img border="0" title="" alt="" src="images/smiles/icon_smile.gif" />

---

Best regards
Allan Ohlfsen

Lars_Pedersen

We use a solution developed by ExpandIT.
You can extract data from Navision and return orders etc.

It is cheap, and you have no direct lines from your web-shop to Navision. It can run on Access or SQL-servers.
http://www.expandit.com/default.htm

John_Tegelaar

For dedicated webaccess (i.e. Employee data), using NF 2.5 SQL and a Java based ODBC driver might give a fine solution also. Not the first choice for a large webshop, probably, but small scale (Intranet?) data exchange/access is quite feasible. The keyword in this is SQL, which allows you to access the Navision database from outside Navision. Using some Stored Procedures and the SQL Server Scheduler, it's also quite easy to produce webpages that are updated each day (or hour, or week, or whatever interval you like).

Just my $0,02

John