Using Lapi to import files and using the import module

Hi,I m contemplating if I should get the import module from opentext to do importing of document files or should I write my own LAPI to do that. Is there a limitation if I am to write a LAPI to do document import?

Find more posts tagged with

Comments

Donna Nalls

Hi Alvin,I am a Livelink consultant and have worked with several clients during document migration/import projects. As such, I have found that cost is the major factor in the decision to purchase the OI module from Open Text vs. writing something custom. Some clients prefer having a module that is supported and upgraded by Open Text because they will be using it for long-term projects; while others have a one-time document migration from a legacy system and we were able to develop custom Request Handlers/Change Agents using the SDK Builder or LAPI; there are also some third-party applications available.I would first like to say that i have reviewed the code in the OI and OE modules and found it to be some of the most beautifully written OScript - and if you have the LL SDK Builder and want to extend the data elements or have custom node types, the objects in this module are extensible, so you can create a custom module and register new objects in the OI subsystems very quickly and easily. The OI Module is one of the nicest import utilities that i have worked with!!With that said, here are the questions you might want to ask:1) Is this a one time only document migration or a task that will be repeated long-term?2) How will you retrieve the data and create the formatted xml files needed for the OI?3) Is there any data elements that you need to capture that are not handled by OI? If so, do you have the SDK so that you can add these components on?4) What is the cost of the OI Module vs. a custom developed application (using SDK or LAPI)?5) If you are going to develop something in-house, what level of LAPI/SDK expertise is available and can you meet any project deadlines that may be in place? What is your company's QA process; will that cause you some additional time in testing, source code control, etc. vs. the proven COTS product such as the OI Module??Best Regards,Donna

Appu_Nair

Pls note Donna's suggestions completely to heart.I will throw my US$0.02 here.I have used OI form OT and BulkImporter from another company.Limitations of OI-If metadata validation is important to you ,ie if a validval is to be entered in a popup is really one in a restricted list, unless you coded that before creating that xml import file you are in no luck.OI I don't think will validate it,only the web interface does it,even with lapi you have to throw routines for doing that.There is a bulkimporter form another company which does validate static lists ,but it does not completely know if the validvals is a table attributes cascading type.OI executes under the Admin's context so permission's check is not going to slow you down even though you can set the createdby to a impersonating user.OI can run in many servers thereby improving thruput which can be done also by suitably spacing,Oscript modules or lapi as well.I am not sure if OI can do customnodes because I have never tried that.I have written OI importer files by bringing things into MSAccess and create the xml files by using access VBA.Any programming language that can do ascii files can be used to generate the xml import files.I have used VBA and perl to do that.

Donna Nalls

As always, good thoughts from Nair...Just to clarify -- i have added custom node types and addl metadata to the OI import by adding a second custom module and registering my objects in the OI subsystem (quite simple and the best development approach). Dan Pidverbny (sp?) did an amazing job on the OI and OE modules.I have on occasion used a little vb app to create the xml files for the OI module using data from a legacy system; the LL xml node format is quite easy if you are familiar with xml...i pointed it out in my previous post only to remind that the files do have to be created in xml format, vs another delimited format you might choose to use with a product developed in-house. I have worked with clients where the DBA set up a database view to query from the legacy system because he didn't have the time to write code to generate xml files. In this case, it was just as easy to develop a Livelink request handler to query the table and create the documents directly in LL. This was a one-time migration and it was more cost effective to develop the R.H. than purchase the OI module.As far as the third party products, you would want to ensure the extensibility of the product IF you do have custom node types or additional metadata. Also, inquire about the error handling - the OI Module writes an excellent status file and also writes out the xml files for any records that failed - this is an extremely useful feature!!!Alvin, i think you can see that there are as many solutions to the task as there are cmpanies performing it....just weigh all of your options and decide what is best for your organization's current/long-term needs.Best,Donna