08-04-2014 11:18 AM
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?”
08-04-2014 01:14 PM
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.
08-19-2014 04:14 PM
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?