Hi,   RESPONSE_SK is not a ID of a unique response record (like one could think of). Instead, it's a reference to a dimensions table CI_RESPONSE that contains "response definitions".   You define "Response Definitions" manually using SAS CI Studio (Definitions tab - Response Definitions), that populates CI_RESPONSE table.   This way you let the system know WHAT TYPES OF RESPONSES DO YOU HAVE.    There you can also populate a channel-specific "Response Channel Code" for that response definition that tells you (and your ETL) how is this response type defined in a channel source data.  It populates CI_RESPONSE_CHANNEL_X_RESPONSE table.  Like if you define a generic response definition "Customer is Interested", it may have a code "CLICKED_A_LINK" for an Email channel, and just "INTERESTED" in a Customer Care channel.   Your ETL then may use CI_RESPONSE_CHANNEL_X_RESPONSE to map to appropriate RESPONSE_SK's based on its knowledge of the channel you are working with and a channel-specific response code. This is a canonical approach. Some customers simplify it and don't use channel response codes. It's not that unusual to just hard-code a mapping to RESPONSE_SK's in your ETL.   Hope it helps! ... View more

Hi, the JSON engine does not need any separate license, it's just baked in there in sufficiently recent SAS platform versions. If it's not there maybe SAS version is somewhat outdated and may be upgraded to a recent 9.4 maintenance release.   Even in this case, and if SAS BI Web Services is still your choice (despite high availability concerns), there are plenty of workaround approaches: You can hard-code conversion logic using good old string manipulation functions without using specialized json libraries or engines You can possibly export json to a physical file and then run whatever Linux command or script you like to operate on that JSON ("jq", python, or node.js), then load the results back. The execution delay may increase with all these back-and-forths, that's correct.  etc   Or you can implement a conversion web service using any other programming environment (not necessarily SAS BI or AWS Lambda) - Java, Python, Perl - whatever works for you and your customer.  If implemented properly, an impact on execution delay may be negligible (like under 5ms easily).    At this moment I'm not sure what's your remaining question and how can we help you further. You may reach for more help on Stackoverflow...   If you question is "are there any controls in SAS RTDM that will somehow teach him to accept hierarchical JSON queries without external conversion, that it does not do currently based on your test" - then the answer is unfortunately no. Good luck! ... View more

If you decide that SAS code-based approach (SAS BI Web Services & Stored Process) is not a fit, and the client is not ready to integrate through the cloud (AWS), then obviously a good old-fashioned traditional programmatic approach still applies. You develop a gateway web service using whatever programmatic platform you and the client like and then deploy it somewhere.   In our experience, with different our RTDM customers where it was required to put something "in between" of a calling system and RTDM (which happens for a lot of reasons), we have utilized a number of technologies: A small custom Java web application deployed to SAS Web Application Server alongside RTDM engine itself Some Python-based implementations SAS Code / SAS Stored Process / SAS BI Web Services (as discussed in this thread) AWS Lambda / API Gateways (as I mentioned in the previous post) A service on Apache Mule ESB (free open source) that can be deployed alongside SAS RTDM A service on other client-owned service bus solution (deployed on their ESB platform)    Obviously, all of that can be made to work reliably (plus a lot of other ways to implement a gateway web service) but requires varying effort to implement. A choice to be made may depend on customer's landscape, performance/HA requirements, customer's preferences, and available talent skill set.   Good luck! ... View more

Hi,   Two responders above call for a programmatic approach using SAS language and its JSON handling capabilities.  They don't elaborate on how are you going to deploy the code so that it executed in real time as a web service, being a middleman between your client's system and SAS RTDM.   Probably, it is assumed that you will create SAS BI Web Service using SAS Stored Process as a backend,  where you will your JSON manipulation code and publish it as a web service.   I don't recall any other built-in way to deploy SAS code to respond web services in real-time. Except maybe through SAS Data Management Server (ex DataFlux) which your client is not likely to have.   SAS BI Web Services (Stored Process-based) approach should work, but also brings some robustness concerns. Depending on your deployment architecture, you may not currently have a fully redundant highly available set of components to run SAS BI Web Services / SAS Stored Process (and it takes more than just one component). I think these deployment challenges can be overcome, but it will need careful and thoughtful deployment architecture planning in advance.    If your client is more or less Cloud-Friendly and getting in-and-out of a corporate firewall is not that of a big deal, I would also consider a lightweight serverless programmatic solution using Amazon AWS Lambda function (in Node.js or Python) + API Gateways.  It's a beautiful architecture, naturally robust, will only require a few lines of code and will be easy to maintain.   It's built-in logging and monitoring metrics capabilities (AWS CloudWatch) can be further helpful in monitoring what happens with RTDM itself (by monitoring queries getting in and out of JSON gateway on its way).   Hope it helps. Good luck! ... View more

Hi Asmaaa, certainly you can do that by creating a Calculated Item called "Message". There is plenty of information of how to create calculated items in SAS MA User Guide.   In your case, your calculated item formula will be based on case statement (case when ... then ... when ... then ... else ... end);   Something like  case when <<category>> = "Worker" and <<sex_client>> = "M" then  "Dear Mr. " || <<Name of the client>> || ", good bye!" when <<category>> = "Student" and <<sex_client>> = "F" then  "Sorry we don't deal with female students, come back later, bye!" else "Hey we don't know you, bye" end   Hope it helps! ... View more

It's unclear from your question whether "all data items" are missing (as the subject line says), or only "a few data items" are missing.   If that's the first, you may have messed up with Subject_ID_1 (Subject_ID_2 etc) custom properties that control folders and data items visibility by subject levels. Double check those, referring to SAS MA Administration Guide that explains custom properties usage.   In only a few are missing, then what differs those that you see vs those that are missing?  If you used Level = ID then such data items are supposed to be missing.  Don't use Level = ID if you need that data item available for selection, use Nominal,   Nometadata instead. Good luck! ... View more

When there is no built-in support for the "Time" type, i'd go with the Text, while providing a clear format explanation and example in the field name / tooltip.   Like "Time to sent a communication (HH:MM, 24-format)": ... View more

Hi,   I think either we or our customer (don't remember already) had a similar discussions with the Technical Support and from what I recall, the answer was "no" (not possible to fully log REST requests and responses in the current version). I would be happy to be mistaken.   If there is no way to do it in RTDM, i'd look towards SAS Web Server (which is essentially a repackaged Apache). There should be plenty of Apache mods to dump requests and responses in a configurable way (based on a URL of RTDM's REST service).   Good luck! ... View more

You are allocating very modest amounts of RAM per server. Some servers should be OK (for a lab environment), but you are likely to run out of 8 gig on a SAS mid-tier server, and on possibly also on RTDM runtimes.    Also 100GB of storage on each tier may be ok for a SAS depot + installation + configuration (even sometimes on a thin margin) but will most likely prevent you from doing configuration backups as you progress through the deployment. I'd go with 150 minimum.   Everything else is OK but may be extraneous, depending on your usage goals for a lab environment. If it's just to get a grasp on the software and its functionality you may not need all 7 servers and might be ok with a simple single-server deployment (or a single-server design + single-server runtime).   If you want to practice solution deployment in a very similar configuration to the one used with the customers in production the it makes some sense.  Even though, for a lab environment you should probably focus on not running out of RAM and Storage (that you are short of), while CPU resources make much less of a difference - unless your goal is to engage in thorough performance testing.   Good luck and have fun!   ... View more

Sorry, that's not the best possible advice. appserver_autoexec gets called way too often in many other situations and you may not want the library to be assigned every time.   The intended solution is to add this library definition into sashome/9.4/SASFoundation/sasautos/mausrexp.sas script. Read the comments there carefully and follow the example provided. It needs to be some macro variable definition, not just a plain libname statement.    P.S> It's definitely a disappointing gap in the product that it requires you to go this far around, rather than automatically and cohesively assigning the library from the metadata definition.  ... View more