Remote Cache 1

[LAMINI]

Greetings

Do we have any Remote Cache experts here?

I get the install module, install RC to primary server, and installing RC on remote server.

What about testing it? I don’t see any documentation on this at all. I know, no surprises here right? As if installing it is the end of it. Very new to the module/product and was wondering if anyone had test procedures or test scripts on just how to test the module on the admin side and especially from the users side. For testing on the admin side, I can zip up the Support folder and have it copy over to the RC Server using RCS services is about it.

While that may suffice for testing the admin portions, I am totally clueless as to the steps on how to test its functionality from the users perspective. Anyone have some basic steps I can follow? I’d ask for some testing documentation but pretty sure that doesn’t exist (please feel free to prove me wrong!).

Thanks in advance!

 

[appnair]

For that what I usually do is assign my UserID to the RemoteCache machine. If you go to the user profile you should see a pull-down of the various RC servers if you have one and is called "My Distant RC" then select that. Now if you hit that RC URL from your machine and try to get to a Document that is sufficiently large you should see a delay and the Document opening. But what is happening behind the scenes is if you open up the RC servers view cache or remote cache directory this document in its entirety will be cached there. Similarly, you go to a folder full of documents and say populate store and forward. When the job runs both main server and RC server has the capability of running jobs in this case. The reason why you would populate from the main side is you are basically caching the items for RC users and vice versa.
If you add a huge document in the RC side and observer the node in the mother ship you will see the node things correct but a 0 KB document. Clicking that will say "this thing hasn't come yet pls wait".This is dependent on the job schedule on the RC side.

This is in a nutshell how RC operates, people adding documents at RC side will obviously feel fastness as the docs will be uploaded later so it's about perception of speed and optimizing it.

BTW I am not an expert so if you wanted an only expert opinion you may ignore this...

Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010

http://www.tek-tips.com/faqs.cfm?fid=2884

http://www.linkedin.com/in/appunair

http://www.livelink.in

 

[LAMINI]

Appu,

A late thank you for your reply. I managed to hose my CS environment trying to do a lab upgrade of 10 to 16. Fortunately I knew enough MS SSMS to do a backup/restore (best way to learn is on the spot right?!)

I had little luck in finding such testing documentation from the user side of the house. As you have already suggested, to at least get a start on testing the software/module from the user side of the house, I created a test account. I stated "little luck" as on the RC 16.2 Admin guide ch 3.9.1 it covers "To Assign a User to a Remote Cache Server". Specifically it states: "On the user's General Info page, in the Remote Cache section, from the Server Name list, click the name of a Remote Cache server.

Though thats about as detail as it gets... all that does is assign a User to an RC server

From here, I log on as that user, and noted that logging on as that user was no different than the Admin user.

It dawned on me that remote cache users would probably not log on to the same CS server, so I used the RC URL:

So I'm stuck at the thought since the option is there, and I have not seen this in the real world, is this typical for RC Users, that they log on to the non main CS URL and use a remote site URL?

From here, is it really a matter of downloading/uploading files as far as testing?

Thank you all!

 

[appnair]

Yes. It's probably a little easier to understand if you actually use a real-life scenario. The company has Corporate Office in Houston Texas and their main manufacturing firm is in Osaka Japan. For purposes of clarity, the Japanese Livelink is the main player as it stores documents pertaining to technical specs in the manufacture of medicine. A wing in the US is responsible for updating the documents that may go through a MOC process, a simple WF, if you will and care, should be taken if specifications have changed for some key medication. The US users will be the RC user when they log in to the RC URL the login is checked in the Japanese KUAF and now they are at a place where they can make changes to existing docs or add new docs. In reality node allocations are always instant as they will cross over the Pacific over the wire and will allocate nodes. If the Japanese people were watching it they will see 0 KB stubs.... After the US closes office its Store and Forward Runs and puts the document version.

OT has actually changed the RC architecture from the old where I or rather the company I worked for and its clients, was actively giving them suggestions etc as to assign users based on RC server or IP address masks so if a user was assigned an RC URL then it will only go there if the IP address maks says he is closer to the RC or not. Further, the version you are doing might even contain an embedded Postgres SQL which may contain localized versions of KUAf, KUAFChilderen, and DtreeACL these all speeds up RC user access and expectations.

OT is also changing the RC product completely as they are going/toying with a hub and spoke method where every system is a full Livelink almost similar to one way or bi-directional replication...so said a big "architect" when I asked him.


Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937
Certified OT Developer,Livelink ECM Champion 2008,Livelink ECM Champion 2010

http://www.tek-tips.com/faqs.cfm?fid=2884

http://www.linkedin.com/in/appunair

http://www.livelink.in