I'd say using databases and SQL is one way to do the job, but it's not necessarily.   While it is true that the built-in Data Grid manipulation functions are sometimes limited, on our projects we do sometimes develop DS2 or Groovy "SAS processes" that cover for the missing functionality not yet available with built-in functions.   Basically, the DS2 or Groovy process can take two (or more) data grids as an input and return one as an output.   Inside, you do some basic programming with cycles, hash tables e.t.c. to implement whatever processing you need (Left Join for instance).  Then on a diagram, you just place the node wherever you need to do the processing and refer to its output instead of a function call.     ... View more

There is a way to make it work with standard data processes, but with some limitations.   You'll need to create a new database table ("input table") where you'd insert your input parameters for a procedure. Plus some unique request identifier (String) to differentiate between multiple concurrent requests.   Then you'll need to create a SQL Server view that calls the procedure for every record in the input table, and returns its result, alongside the original request identifier from the source table.  If I'm not mistaken, you may need to use the "OPENQUERY" function in the view (can't say exactly, i'm much more of Oracle guy than sql server).   In RTDM, you can then have a sequence of 3 Data Processes: Insert your input values to the input table, and use Event.Identity as a request identifier Read from the view, and filter on the request identifier = Event.Identity as criteria variables. Delete a record from the input table (again using Event.Identity as a request identifier).   The catch is that you need to make sure the procedure you are calling doesn't have any unsafe side-effects and is safe if sometimes called extra times repeatedly.  With this solution,  there will be situations where two or more requests are processed concurrently, and there will be more than one record in the input table - so the procedure will be called extra times. Depending on your use case and the nature of this procedure, it may or may not be OK.   If it's not OK, then the way to go develop is a DS2 or Groovy script process that will call the procedure with explicit SQL.    ... View more

Hi,   First of all, this is a generic Groovy development question, it seems to have little to do with the fact that you are running it from RTDM. You could create a similar script (substituting some input parameters) with the same REST call and run it as a standalone Groovy program, and likely get the same issue.  Naturally, stackoverflow.com would be the place to ask.   A number of articles are being googled by "Groovy HttpResponseException Not Found". All point out to the issues in URL and Path formats.   Try this advice: https://stackoverflow.com/questions/33387753/groovy-grails-get-httpresponseexception-by-using-httpbuilder   Would be creating a RESTClient for 'http://sgbdcmpweb01:7980/' URL, and using path 'RTDM/rest/runtime/decisions/mpgPortout' or something like that.     ... View more

This is a fairly typical task and typical setup. Congratulation on moving in the right direction with the two-staged campaign and intermediate coupon storage table.   What you actually need is that 2nd communication to store somewhere what coupon IDs were communicated for each customer.  This way you could link all facts together using coupon ID.   If SAS MA supported dynamic variable-based treatment attributes (like SAS RTDM does), there would be a natural and beautiful solution - you assigned a Treatment with a dynamic attribute ("coupon code") that you'd populate using the coupon code exported variable. And it got stored to the dynamic_treatment_attribute_ext table.  Unfortunately, this is not the case as SAS MA still lacks this feature (treatment attributes in SAS MA can not be truly dynamic based on a variable) What you are supposed to do is to Export the data from your communication (customer id, response tracking code, today's date, communication code etc - it's optional as you can derive it from the response tracking code) + coupon code and store it in a new custom table. You can use a separate (2nd) Export Definition (Table - append) in addition to the one which is already there. Or you can rely on what export definition is already there - exporting to the channel (is it a file or a table?) - and use a Post-Process that picks up this piece of data and stored it for long-term usage in the table you need.   If you only export one coupon code per contact, then some people would write a post-process node that stores the coupon code to the EXTERNAL_INFO_ID1 column of CI_Contact_History table - thus avoiding the need to create a separate table. This is an actually better solution as it makes easier for you to maintain data consistency - whenever you delete records from CI_Contact_History for any reason, the coupon code will go with them.   ... View more

Hi Angela, this was actually in my first response - I pointed you to a specific page in the SAS RTDM Admin Guide document. It has the example code. Can't you find it there? ... View more