Siebel Integration

scott

One of my clients is using Siebel for sales quotes. Siebel exports new customers, new quote headers, and new quote details to three text files every two hours. Customer file names have prefix ACCT, followed by year, date, hour and minute. Quote Header file names have prefix QTHR, followed by year, date, hour and minute, and Quote Details file names have QTDL, followed by year, date, hour and minute.

To import these files one by one to Navision is too time consuming. Is it possible to automate the importing process? Any OCX I can use?

Thanks.

John_Tegelaar

Believe this task can be automated by using the Scheduler utility from ExpandIT Solutions (free, see the Download section of this site), or their ClientControl tool (not free, demo also in download section), to start your Navision import (Dataports?). If you are running SQL Server version, you could use Stored Procedures being called the Job Scheduler.

John

mfabian

I had the same problems in three customer projects so far.

In one project we solved it via a linked table in MS-Access: Export data (Export from the point of view of Navision) is being written to a Navision Table. This table is accessed by MS-Access via ODBC (linked table). Import works the same way: Access writes the data directly to a dedicated Navision table. It works but I'm not able to tell anything about performance as only relatively low amounts of data are being transfered this way.

In the other two projects we have the same situation you describe: The thirdparty program sends data by storing them into textfiles in a dedicated directory.
In one project few but very large amounts of data are being exchanged. This happenes manually by starting an import/export job on either side.
In the second project a hell lot of very small messages have to be exchanged and performance is a key issue. We solved it very simple and efficiently: Flat-Files (as described) are being created by each program. Each program constantly scans every second his Import-Directory (which is of course the Export-Directory of the partner application) processes the import file and - if necessary - sends an Answer which is also a simple textfile.
Each processed message (=file) is being archived/deleted afterwards.

We did some time measurement for the following scenario:
1) Navision sends a message (writes the file) and waits for the answer.
2) The Partner-program reads the message, does something, and sends an answer message back.
3) Navision reads the message.

Even during heavy workload this whole way doesn't take more than three seconds which is quite good as every program scans for messages only every second.

In Navision three simple tricks were necessary to reach this performance:
1) There is a dedicated PC with only Navision installed who is doing nothing else then scanning regularily (every second) for new messages and processing them.
2) If several messages are in the queue the messages are being read in alphabetic order of the filename. The first letter of the message ("A" to "Z") describes the message-priority thus making sure that "C" messages are being read before "G" messages while "A" messages have the highest priority. To create the whole filename this priority-letter is then followed by year, month, date, Hour, Min, Sec, Message# to make sure that messages of the same priority are being read in order of creation.
3) Every message exported by Navision has a unique message-ID, is logged and the log (a navision table) contains information about which station (user) originated the message and what the message is all about (recordtype). As the answer will contain the original message-id, navision can determine which station/user is probably waiting for an answer and react accordingly.

---
Conclusion: Do not waist your time and energy with OCX Server/Client as they will ...
a) most likely be slower than flat-files
b) be unreliable: If one of the stations has a crash and the application has to be restarted, Messages accumulate in the Input-Folder but the messages are still available, can be processed - with little delay after the restart of the failed application - and everythings works smoothly again after the import-messages have been processed.
c) much more expensive to program, to maintain and to test.

Marcus

---

Marcus Fabian
m.fabian@thenet.ch
+41 79 439 78 72

[This message has been edited by fabian (edited 03-08-2000).]