Me and my colleagues recently used this framework for transporting a custom subtype that we designed.We were helped by a kind OT developer All in all it saved our administration team from running XMLEXPORTS and XMLIMPORTS but the key factor is that needs to work for the transport code to work.
Recently OT announced a “Transport” mechanism. Users working in SAP etc are familiar with such a mechanism as changes to a baseline system are marked as configuration changes and ported to other systems.While I am oversimplifying this in a SAP deployment since so many code modules have to be configured it is impossible for an admin to remember what all has to be changed hence they decided at least 20 yrs back an enterprise program needs a transporting strategy as well.
Now lets look at how livelink gets deployed in an org. Mostly Livelink is deployed to address a document management pain/problem.Some consultants or a admin/developer who gets trained in livelink or somebody who has some documentation starts to install/configure this.assuming the person(s) have some common sense and tickets later it is working.Actually the first time install guide is very nicely written and it is mostly a “next” “next” kind of install.
Having configured it the person/persons start modelling the solution.It may involve setting up folders,categories for collecting metadata,classifications for alternative taxonomies,RM classifications ,Permissions(ACL) etc. OT and a lot of ecosystem partners take the money to sometimes set it up.You can make it complicated or simple.
Ok now that it is past the POC phase the next phase is the perhaps a TEST a more formalized place.Now comes the first shock how do I not necessarily duplicate all the work I did on a lower system.Fortunately while there was no advanced GUI or “Transport Bench” mechanism many of these building blocks can easily be transferred by XML IN/OUT operations.Smarter modules such as Classifications/RM anticipated the need for this so they did make their own transport mechanism well ahead of OT. But almost everything one could accomplish in a poor man’s methods
Now in controlled industries like Pharma etc this manual stuff was sheer heresy so companies like Global Cents made excellent products
So why the Transport now. My theory is the entry of integrations between SAP and Livelink.In fact the web services also was something my thought SAP forced OT’s hands.Many SAP customers are now getting a facelift with livelink doing a lot of backend services,pretty gui’s etc.
Here’s an interesting fictitious exchange between different players in a Integration meeting this is circa 2010,2011
SAP Basis Admin-Here we got the xECM thingy and archive server thingy going with OpenText (Notice OT in that because there is no product called that),I sthere anything else you guys need and can I close the client.
OT Consultant- Oh sure but on the next client you have to give me high access to edit the connections,change a few GUID’s(dataids) etc.
SAP Basis Admin-What the …..That means you have to do all this again
OT Consultant-Not everything just a few tweaks and pointing to the livelink admin..Hey Kishore where are we on the next OT system. Have the ELIB items(categories and folder looking things) coming along
Livelink Admin-I did that according to documentation.
OT Consultant- How about the dataids did you run the queries I gave you for the re-mapping
Livelink Admin-Yeah everything is there
SAP Basis Admin-All the while thinking that what are these guys talking about re-configure every system.I have about 20 different clients I have to maintain.
OT Consultant-Just to prop up the SAP guy,well you know our guys in Germany are coming up with a Transport mechanism just like yours…
Well finally after a lot of back and forths the project is a success
If it is just a DMS project a lot of us have no problem using the old methods.
I am pretty sure the transport mechanism is a GUI version of XML Export/XMl Import.
The reason why I wrote this is recently a friend asked if he would be lucky in a project that would not have Object Importer(OI)/Object Exporter(OE) and its RM variations.
I told him this
OI/OE can be leased from OT for a price .They used to entertain that.
With XMLEXPORT/XMLIMPORT here are a few things you would run into.
- XMLEXPORT is almost available universally but the reverse is not true universally.
. So if one exported PhysObjects the corresponding import will fail.
- XMLEXPORT will choke on big documents and the number of nodes because of DOM parser limitations. In OE they bundle the file separately so they can get more throughput even though the code invokes a DOM parser there as well.
- XMLEXPORT/XMLIMPORT is based on source dataids which is not going to match targets. So if you find the xml exported file and change the category id’s to match the target it will work.
- XMLEXPORT/XMLIMPORT does not understand the hierarchy. For e.g OI will create nodes as it wants enterprise:folder1:::::::::;;;folder99. In XMLEXPORT import you would have to export and follow the reverse process. So if a child object is nested way into a path OI will handle it XML import you will have to handle it
- Most people will use XMLEXPORT/XMLIMPORT with lapi code so they can manage a lot of things with code in java or a .net lang
Now that GUIDS are part of 10 and 10.5 I do not know how that affects anything
OI/OE is kind of a framework .So with that I was able to transport compound email,email folder and email in a project with relatively less coding.
Readers-Please tell me if the Tranport Bench from OT is good and easy to use and it resolves conflicts et al and I will delete my post.