Promoting business rules to the Data Management Server

[AnnaBrown]

Hi everyone,

Recently, a thread went around at SAS about propagating business rules on the server environment, and I wanted to get the community’s perspective – similar to the profiling large text files entry. We’ll take your thoughts, then I’ll share what the SAS experts came up with. Here’s the question:

“I’ve developed rules and tasks on my local instance of Data Management Studio. I also have a job that uses these tasks as part of a Monitor node. I now want to promote these rules and tasks to the server and run the job there. How do I get rules, fields, dashboards and tasks onto the server?”

Anna

[jakarman]

Anna your question is about promoting with the Data management Server. I would prefer to view at the promotion/synchronization logical process (develop test accept production lifecycles).

When you develop "business and tasks" I qualify that kind of objects as "code" in the business domain lifecycle.

Anything as "code" objects does not contain something like a specific name/address order price account information being processed operational (data). This split of object-types does only occur in the business domain area not in the technical infrastructure area (operating sytem, networking) and not in the middleware (DBMS systems, Communications tools,  SAS etc). I am seeing a three leveled D,T,A,P life cycle process that is having a rather classic approach.
Still it is very confusing as too many people are mixing those up in a more complicated way.

The last one of that is even more worse to get accepted. That is classic development approaches (like ETL) are not suited with analytics.
The reason is you are needing real production data to process for development not faked one. It can be a good sample but still all is real life data in development.
I am not the only one saying this... http://blogs.sas.com/content/sascom/2014/07/23/standard-etl-tools-are-not-designed-to-support-analyt...

This is a conflicting  one with classic IT approach as there developers are nor allowed to access production.  All kind of barriers are build (network segements, machine namings) to enforce that data isolation.

Regulations are coming in with mandatory monitoring (SIEM and operational) guidelines.

What this implies is:

- you need a lifecycle process (D,T,A,P) of business-rules developed on production data.

- This lifecycleprocess must run on segregated environments within the "production domain" (data isolation).

- When it is necessary to isolate machines (performance or access reason) you will at least two of them

  It is possible with a not so often promotion process to manage those stages by definition in time.

  Stop developing go for testing after acceptance and promoting allowing new development.

- When changes will come in higher rate (agile/acrum) the more physical/logical implementations are needed.

- When devlopers are not allowed the operational machines but must be able to see the production "business code" there must shadows made available.

You could end up this way with a lot of promotion and synchronization processes.

Sounds complicated but a figure kan help.

This is a N-P-K dilemma at most implementations.  

[AnnaBrown]

Thanks Jaap, appreciate this info from a best practice perspective. Here’s an approach from a SAS expert on how to do this in Data Management Studio specifically.

Create two repositories on DM Studio, one for the DM Studio repository and one for the DM Server repository. In each folder, create a directory called “Shared Data” (no quotes). After this, you may need to close and reopen DM Studio. Highlighting Shared Data should display the rules and tasks in the repository. Highlight the rules you need to migrate, right-mouse-click and select “Copy to folder…” A pop-up box should display.  Navigate to the target Shared Data folder and click “OK.”

Do the same for the tasks.

This should work for any rule or task. Keep in mind, though, if you change the name of a rule or task, new entries are added. So, if the rule was initially named “NULL Check” and is now named “NULL Invalid,” a new rule called “NULL Invalid” is inserted into the target repository. Even if the name is off by one character, a new rule or task is inserted.

When copying the rules, any field used by the rules is also copied. Dashboards and other objects can be migrated using Business Rule Manager specifically.

Note that this will work even if your server and client are not on the same system, but they DO need to connect to the same database. The rules and tasks are fully contained in the database portion of the repository. 

Community members – do you have any other ideas on this topic?

[Rama_V]

@AnnaBrown you previous post explains very well on the steps to promoting.

I understand this post is very old. but just thought to share what I am facing some challenges around this. 

Our Data Flux repositories are not on a database but on file system as Data flux creates its repository database .rps as extension. So our developing repository file local.rps is location of my choice location on our local machine. Similarly there is .rps file on the linux server located at  "install-dir/DataFluxDataManagementServer/2.6/dmserver/var/repositories/Server.rps".

I think in these situations to promote the business rules following below steps will work.

1. Firstly I need to copy the server repository file  Server.rps on to my local machine. Connect Data Flux Management Studio to the copied Server repository file.

2. As per previous post by Anna, copy the business rules to server repository through Data Flux Management Studio on my local machine . Once the server repository is updated on my local machine then copy that file back to Server.

Unfortunately, I do not have permission on Server repository file. If I sort the permissions on the repository file then can I able do the promotion?Anyone?