Skip to Content

KM transports: Part I

KM transports: Part I

Whats it all about:

                                                  In my last web blog, I was trying to bring up some configuration modifications with respect to Knowledge management. Please refer KM Customization – Change the layout, context menus as per your choice! for further reading about this topic. In forth coming web blogs we would play around with much more configurations. But in this series of blog we would design a strategy for KM transport.

The strategy:

                                                  As of now we would design a transport strategy for KM. Lets assume a scenario that KM is being worked out in a sand box or a dev box and then is required to move between Dev and Q, Q and Prod several times. We do the task in sandbox first and then implement in Dev, move it to Q. Do a rigorous testing with the current config, content and then after we pass it to production. In between these processes, there would be several transfers occurring typically from dev to Q (when the testing defects are fixed), from Q to P (when production support issues are cleared out). 

Decide what to transfer and how:


                                                  Nextly I wanted to explain two different categories of KM that work hand in hand. KM is basically a document management system that has some document typically categorized as “Content”. But that is not where KM stops. It specifies many properties and constraints for each of the folder and the documents. Typical properties would be when is it created, modified, who is the author for the document/folder , what is the current version of the document. Typical constraints would include who sees what documents, who has what level of privileges for which documents. All these properties and constraints are categorized as “Configuration”. So in KM we upload document separately and we set the configurations for those repositories separately. And so does the transports go. Separate transport for config and a separate transport for content.

The methodologies:

                                                  So we decided the first step in our strategy, that we bifurcate our KM transport, one for content and the other one for config.  As far as I know, I can only suggest one staright forward way for config transport. But there are several ways the content transport  process can be carried on (atleast I know there is more than one way if not several). For content primarily we would do it either by,  1. ICE methodoly    or 2. Web Dav methodoly

ICE Methodology:

                                                  ICE stands for “Information and Content Exchange”. This is a service that is being used in portal for content exchange, as the name itself suggests. Now having said this, I don’t wanna eloborate more about this service with what I know. Because whatever I have known about it is in the help portal as well and some might have come across it already. So here we go with the link, 

The portal runs this service as I said you before. In order to confirm it, go to KM content and check for the list of repositories under root. You would find one named ICE, which is for the ICE service. 

Web Dav methodology:

                                                  Web Dav stands for Web-based Distributed Authoring and Versioning. This is another methodology for KM transport for content only. I have a separate inclination with this methodoloy as it makes life easier ( Im sorry! That is personal. I like both the methodologies). Its basically a windows folder  type representation of the whole of the KM repositories (now I have a hunch that you too are inclined with this methodology). Anyways, instead of me rewording further information about this protocol, here we go with the reference, 

I would say in forth coming web blogs how to check this service on portal. It isnt as straight forward to check as what ICE was.

End of Blog:

                                                  I started to eloborate the KM concepts, I ran into the risk of exceeding the content length for the web blog. So lets see the transports of each category with all possible ways, their challenges, their obstacles, their pros, cons and all-in-all in the forth coming web blogs. Summarising that the web blog series would possibly go in this flow,  1. KM config transport (I will try to cover both import and export in the same blog) 2. KM content transport for ICE (I will try to cover both import and export in the same blog) 3. KM content transport for Web Dav (You know what I will say, I will try to cover both import and export in the same blog)  Sit tight untill then!

Be the first to leave a comment
You must be Logged on to comment or reply to a post.