I am working out a posibility of integrating navision to other softwares in the market. to ensure full integration with navision. i realise a batch update integration with navision is not a problem, as a simple batch update to navision can be achieved using a dataport or a temporary storage table in navision. but, what about real-time integration to navison? how possible is a real-time integration to navision? eg. when the third party product attempts to delete a record, this will be reflected in navision immediately (Real-time) and at the same time validates the triggers in navision. any experiences in this? tq.
I don’t believe you can cause Navision triggers, including VALIDATE, to execute from an external software product including (I think) C/FRONT. Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner
if you cannot validate the navision trigger even with c/front, there would be no difference between manipulating navision with c/front and c/odbc in terms of functionality…
Yes, Cfront and ODBC is very similar and have the same limitations. To do real time integration you can: 1. Have allways running codeunit on navision and scan external data source over OCX. 2. Use NAS. 3a. Use Cfront or ODBC, but you should implement the same code of validation from external application. 3b. Push data from external source over cfront to temporary table. Runing fin.exe scans this table for data and validates it. What to choose, it’s depends what you like and on money.
Dalius gives a pretty good list of the options. I like an approach that involves keeping a codeunit running that periodically scans for data to be processed. It can be scanning either a Navision table that the outside application pushes data into, or scanning for the existance of an external file where the outside application deposits data. Two significant differences between using C/ODBC and C/FRONT interfaces: 1) C/ODBC can be done using non-programmer tools, in some cases even a knowledgable end user can set up the C/ODBC connections 2) There have been several instances where the C/ODBC interface didn’t work all that well while the C/FRONT interface has generally been pretty robust. Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner
As Dave mentioned C/FRONT is more “robust” than C/ODBC and it’s a fact. From my experience C/FRONT is VERY reliable as far as C/ODBC is concerned it’s not quite there yet. As soon as you start doing something complex/fancy with Crystal Report it will make C/ODBC fail miserably. I for one never like C/ODBC because for his lack of reliability. I am the only ANTI-C/ODBC here ? ###### tarek_demiati@ureach.com
No. To use a US term: C/ODBC sucks! We once developed an interface to Internet Shop that was based on C/ODBC and it never was really good. Although we, after weeks of testing and refining, got it to work very well, then the speed was not good at all. Our programmer instead created an ADO interface to Navision based on C/FRONT. That was way better, but today I would prefer to use Application Server for any Internet / Web connections and either COMMERCE GATEWAY or COMMERCE PORTAL. For smaller and more hardcoded situations I would still consider to use C/ODBC, or even a simple file interface. C/ODBC is fine for updating spread sheets, doing mail merge etc. Everything extracting data. When it comes to updating then I would prefer C/FRONT and the use the approch with the CODEUNIT - actually I would use a form and the OnTimer trigger. Normally I would create a buffer-in table in Navision and have the external process update this, and the place the result in a buffer-out table, that the external process could check to see the result. This is btw. pretty much how the application server works. Best regards, Erik P. Ernst, webmaster
well yes, but your method of updating a form with timer is still a batch job, only difference is that the interval is shorter. and one more thing, i have heard of Navision Application Server one too many times, but i still do not know the functionality and the definition of it. maybe someone can clarify this with a practical example? one more thing, what is ADO?
ADO = Active Data Object This is a way to create a ActiveX control, that you can use from you ASP webpages (using VBScript), other VBScript or VBA applications (i.e. Excel). Best regards, Erik P. Ernst, webmaster
There’s one more solution to interface with external programs: Use SQL. In fact, interfacing is one of the main reasons to select SQL. Apart from having much more freedom in selecting your tools to access the tables on the SQL server, you can also use the SQL equivalent of table-triggers to prevent, for instance, deleting a record. John
John’s right, you can do a lot with SQL. But I would caution against creating functions that are mixed, with some pieces being done in Navision and some in SQL. It would be easy to end up with intertwined code that would be very difficult to debug and maintain. Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner
but when sql comes into the picture, can navision triggers be fired externally? you will have to rewrite all the procedures and restrictions in sql procedures right?
To Jordan: Correct, you cannot fire the Navision triggers externally. Any of the Navision validations you want to occur must either be replicated or fired from within Navison. Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner
but i have heard of a 3rd party product, that acts as an agent that opens navision and executes a script file, which will most probably do things like inserting records and posting… i can’t remember what it is called… has anyone use this before?
You’re describing an “automoton” acting as a Navision user, working from within a Navision logon? If so, then it’s not really working externally, but more like a keyboard macro. That seems feasible, but I’m not familiar with such a product. Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner
Don’t forget That from 2.65 and in Attain Navision can respond to events triggared from an external services. If you define an variable as an automation server and set the property withevents to yes, you will see some triggers put at the end of the codeunit corrisponding to the automation events. So all you need to do now is create a NAS or have the codeunit with SingleInstance set to true to respond to you external process. Your external program will work with Navision in real time. If you want Validation then this can be written in CSide using all of Navisions normal triggers. It is much less bother than ODBC or even Cfront. Paul Baxter
quote:
Originally posted by Tarek Demiati
As Dave mentioned C/FRONT is more “robust” than C/ODBC and it’s a fact. From my experience C/FRONT is VERY reliable as far as C/ODBC is concerned it’s not quite there yet. ###### tarek_demiati@ureach.com
In my opinion, C/ODBC isn’t so flexible as C/FRONT. But I not these questions to my answers:- How can I access to BLOB field and extract his value via C/FRONT ?
- Why I cannot use C/FRONT as COM in my web application (or why I can’t find cfront.tlb file to create my own ‘Automation’ object and link cfront.dll file into it) ?