nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD 5.5.1 dependency on OpenAPI ?

tvaughan

Hi,

I'm thinking that I need to use some OpenAPI functionality, and as I was purusing through the OpenDeploy 5.5.1 (for Solaris 8) manual to get more edumacated, I became somewhat confused.

If you have a stand-alone OpenDeploy 5.5.1 installation, you automatically have OpenAPI installed, right? From a second machine (my OD admin box), I'm able to remotely connect to my standalone OD installation, I'm able to review the deployments on my stand-alone box, etc, so I assume that when I installed OD 5.5.1, it auto-installed the functionality required to remotely administrate it, which I'm assuming is called "OpenAPI"

I guess I have two questions:

1) When I run "ps -ef | grep IWServiceServer" on this stand-alone box, I don't see anything running. Doesn't that indicate that OpenAPI ain't installed? If so, then why is my admin server able to connect/admin my stand-alone OD box?

2) Is there a published API of OpenDeploy services exposed via OpenAPI / RMI ? I looked through the OpenAPI developer's guide and didn't see any mention of OpenDeploy services.

TIA,

Tom

Find more posts tagged with

Comments

Migrateduser

OpenAPI is only needed for the Admin server machine (the admin server needs to be installed on the same machine as your operations server/OpenAPI server). There is no OpenAPI server running on the odbase and odrcvr servers, but there is communication via RMI through default port 9173 (on the odbase/odrcvr servers) and the admin server.

As for an API, there is not one that is exposed currently that I know of. You might be able to pick some things appart by looking at the iwodstart scripts (perl or the shell/batch script) to see what sort of things can be done via java directly (keep in mind however that this API is not exposed and if may change without notice until there is an exposed API).

I believe that there may be plans for an API coming up in later releases.

tvaughan

Nuts . . . . I was afraid of that.

So, unless I go munging through a bunch of code (some of which is probably compiled/library code), there's no way I can programmatically tap in to the kinds of commands that get issued by an OD Admin GUI??

That's a shame . . .

Tom

Migrateduser

What sort of things are you looking for? Just user access manipulation or something else? If you have anything in particular that you are looking for you may want to mention it here or file a support request to get your feature requests looked at for later inclusion.

Right now I think the only thing that others have asked for is a way to manipulate the user access db for deployments/servers via an API.

tvaughan

I have a deployment currently set up that: starts on my TS server (w/ OD5.5.1 base), sends a filelist to a QA server (also with OD5.5.1 base), executes a DNR script on the QA server that wraps an iwodstart command to do an additional deployment off that QA server to production servers.


1)  TS    -------->filelist-------> QA
2)  TS    -------->filelist-------> QA  //// runs DNR
3)  TS    -------->filelist-------> QA  ------>deployment---> Prod

What I'd like to do is write a little java routine to piggy back on the RMI channel between my TS server and my QA server so that I can send a signal to the QA server to kick off that script called by the DNR without the first part of the deployment happening.

In otherwords, I'd like to somehow get access to the DNR and iwodstart methods that must exist in the QA server's *.jar files somewhere. So, in the diagram above, I'd like to do something like this:


2)  TS    -------->RMI call-------> QA  //// runs DNR
3)  TS    -------->RMI call-------> QA  ------>deployment---> Prod

Of course, I could write my own stupid little socket engine, but I like to re-use where possible.
Tom

Migrateduser

well... maybe I am missing something, but what you seem to describe is a two tier deployment (something for which I believe OD5.6 has some improvements for).

I believed that the way that this could be done currently was just to have the DNR on the QA server call the secondary deployment.

Can you clarify the below statement:

"What I'd like to do is write a little java routine to piggy back on the RMI channel between my TS server and my QA server so that I can send a signal to the QA server to kick off that script called by the DNR without the first part of the deployment happening."

Do you mean that you want the QA->Prod deployment to kick off before the TS->QA deployment starts to transfer files (or do you mean something else completely different)?

Sorry for all the questions, I am just trying to understand what you are attempting to do and see if there are already planned enhancements that would help you.

tvaughan

Hey,

You understood correctly. Currently, it is a DNR script that kicks off the secondary deployment. Problem is, that the concept of a "DNR" is tied to a deployment.

I'd like to call that script and/or the iwodstart command which that script wraps around via RMI, and I'd like to be able to piggy-back on the current RMI communication channel between 2 OD installations.

So, to clarify: a filelist deployment is sent from TS (call it server X) to QA (call it server Y). If the deployment is successful, a script on server Y runs that does another deployment to server Z. The deployment from Y to Z is not necessarily based on the files sent from X to Y.

Sometimes, I want to run the deployment from Y to Z without having to first do the deployment from X to Y. I could telnet out to the box and kick off the script by myself, but I'm trying to hook this up for some users who aren't that savvy.

I'd like to create a custom menu item on server X that -- via the existing RMI channel -- runs the deployment from Y to Z.

I guess part of what I'm asking is for the functionality in OD 5.6 that lets deployments be run via the OD admin GUI with variable substitution. I'm not wild about that feature, though, because none of my users use the OD admin GUI -- I've abstracted all that for them through custom menu items, and a lot of them would get completely befuddled with 2 different GUIs, not to mention the number of variables they'd have to fill in.

Tom

P.S.-- thanks for caring. These boards have seriously improved in the last 12 months, thanks in part to people like you, fish, Koh, et. al.

Migrateduser

Ok, I think I found a feature request that might fit the bill for your need (its asking for an API for starting remote deployments). I don't know the company that you are working for, but you may want to open a support case and ask to have your customer added to FR 30519.

It doesn't look like this feature made it into OD5.6, but there are other customers asking for this same feature.

Test.txt

Migrateduser

At present, the only ways to initiate deployments are via the CLT or the Admin UI. The RMI interface to the Base Server is not exposed and can change from release to release.

Having said that, we've gotten requests for a programmatic interface to the Base Server functionality. This is something that is being investigated, but no immediate plans to release something.

OD 5.x has a "multi-tiered" deployment capability that perhaps would help with Tom's scenarios:

In the case of the first deployment kicking off the second deployment, the first deployment config would refer to the second deployment config to kick off. No need to use DNR.

Example: Deploy from systems X to Y, then Y to Z. Deployment config "foo" on system X refers to deployment config "bar", which lives on system Y.

In the case of remotely kicking off a deployment, sounds like you don't want to use the Admin UI or log into the remote system. Perhaps you could kick off a different multi-tier deployment. The first one wouldn't have to actually deploy any files. It would then automatically kick off the deployment on the second system.

Example: Dummy deploy from systems X to Y, then real deploy from Y to Z. Deployment config "dummy" on system X refers to deployment config "bar", which lives on system Y.

Todd Scallan
Senior Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

tvaughan

Hey Todd,

I wrote this whole DNR script kicking off the second deployment before the multitiered deployment syntax was available (back on 5.0.1, if I recall correctly). I should probably port it to take advantage of the new syntax (in all my copious free time).

I was mulling over the whole "dummy deployment" just for the sake of kicking off the DNR, but I just wouldn't respect myself in the morning. . .. it just feels so . . . .dirty ;-)

Tom

Migrateduser

Yeah, I had to wash my hands after offering the suggestion. <grin>

BTW, I've added you to the customer list for FR 30519.

Cheers,

Todd Scallan
Senior Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com