Absent Member.. HPisT Absent Member..
Absent Member..
2090 views

Anyone successfully set up an OO RAS (remote action server)?

Jump to solution

Unfortunately the documentation is confusing and mentions a OverrideNRAS content pack that we can not find. I'd love to hear that a real humanbeing was able to get one set up, and what caveats to look out for. 

 

thanks in advance.

Labels (1)
Tags (1)
0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

Re: Anyone successfully set up an OO RAS (remote action server)?

Jump to solution

Hi, 

Since you said you are using 10.20 what i wrote above applies to 10.20 without any other concern about it.

Regarding the overrideNRAS  property i will try to give you some general guidelines (withotu an actual use case it is hard to give out specifics). 

As you may know/noticed all OO workers (the central and RAS workers) are set to belong to some groups. All executions from central will run on workers beloging to certain groups, defined during authoring using group aliases and override properties. By default all out of the box (ootb) content will run on the default group RAS_Operator_Path and all workers will by default be assigned to this group. 

During usage it may be needed to have certain flows run only on certain workers (either due to content limitations like .net content can only run on windows workers, or environment requirements where some content can only run on the worker's localhost).  In order to easily manage this temprary or permanent worker switch all operations have an override property called overrideNRAS (for .net content) and overrideJRAS (for java content).  In order to use these properties  you need either in the flow to have variables with the name overrideNRAS (overrideJRAS) and as value the name of a worker group (ex: windows workers) or create system properties  with the name overrideNRAS (or overrideJRAS) and as value the name of a worker group.

Using system properties will enforce the override groups on all central content, while using flow variables will enforce the groups only during execution of a certain flows. 

There is no content pack containing these system properties, however you can easily create a content pack in studio with these properties and deploy it to central.

By default you don't need to do anything related to these properties in order to just have another worker available to run flows. 

If you give us a specific use case we can help you further.

Regards,

Vlad

4 Replies
Respected Contributor.. relent0r Respected Contributor..
Respected Contributor..

Re: Anyone successfully set up an OO RAS (remote action server)?

Jump to solution

I'd say most people here have configured them before. 

Do you want to describe your use case and which point your up to? (i.e installation, config, usage)

0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Anyone successfully set up an OO RAS (remote action server)?

Jump to solution

Hi,

Since you are talking about content packs i think it is safe to assume you are working with oo version 10.x. As relentOR said we would need more information in order to help you furthere because from your post it is clear that there are some missunderstandings. I will try to help you with general information regarding setting up RAS. Since you have not specified oo version I will cover only rhe regular RAS (since that is more common), the newly introduced in 10.60 reverse RAS will only be covered if you need it. 

For regular RAS you will need the url of the central (http[s]://<central_host>:<central_port>/oo ). if authentication is enabled you will also need a central username and password which has either the Administrator role or the manage topology permission. If the central url is provided with https and central was installed with a CA (third party) signed certificate you will also need the root CA certificate of central (the .cer certificate).  During installation select only RAS, for 10.60 select the type of RAS as regular RAS, provide the central url and all the other data i provided (as needed) and clik on test connection. Once the test connection succedes finish the installation  and your RAS will be installed and registered on the central you provided. 

By default all RASes are disabled in central after installation. In order to be able to use this new ras it has to be enabled from central's topology screen. (system configuration -> topology).

For the override groups (overrideNRAS and overrideJRAS) the discussion is longe than that and it touches worker groups and in order to drill down into these properties it will take too long and will overcomplicate the thread.  Please ask specific question regarding these properties, and we can look at them on a per  question basis. For more info about this see the concept guide.

Regards,

Vlad

Absent Member.. HPisT Absent Member..
Absent Member..

Re: Anyone successfully set up an OO RAS (remote action server)?

Jump to solution

Thank you so much for your time replying. I am trying to set up an OO RAS for version 10.20 but the documentation has been confusing. This is b/c we are DCAA customers and not OO proper. Also the OverrideNRAS is where we are having the most issue. Is it required? the documentation references it but doesn't explain it's purpose very clearly. 

0 Likes
Micro Focus Expert
Micro Focus Expert

Re: Anyone successfully set up an OO RAS (remote action server)?

Jump to solution

Hi, 

Since you said you are using 10.20 what i wrote above applies to 10.20 without any other concern about it.

Regarding the overrideNRAS  property i will try to give you some general guidelines (withotu an actual use case it is hard to give out specifics). 

As you may know/noticed all OO workers (the central and RAS workers) are set to belong to some groups. All executions from central will run on workers beloging to certain groups, defined during authoring using group aliases and override properties. By default all out of the box (ootb) content will run on the default group RAS_Operator_Path and all workers will by default be assigned to this group. 

During usage it may be needed to have certain flows run only on certain workers (either due to content limitations like .net content can only run on windows workers, or environment requirements where some content can only run on the worker's localhost).  In order to easily manage this temprary or permanent worker switch all operations have an override property called overrideNRAS (for .net content) and overrideJRAS (for java content).  In order to use these properties  you need either in the flow to have variables with the name overrideNRAS (overrideJRAS) and as value the name of a worker group (ex: windows workers) or create system properties  with the name overrideNRAS (or overrideJRAS) and as value the name of a worker group.

Using system properties will enforce the override groups on all central content, while using flow variables will enforce the groups only during execution of a certain flows. 

There is no content pack containing these system properties, however you can easily create a content pack in studio with these properties and deploy it to central.

By default you don't need to do anything related to these properties in order to just have another worker available to run flows. 

If you give us a specific use case we can help you further.

Regards,

Vlad

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.