Let's talk about best practices in CDI. No matter where you're at in the process of using CDI - beginner, comfortably competent, expert - best practices are important. I'd like to start with a couple of things on my "Never Do This!" list. Sometimes I hesitate to share these. After all, if you didn't know you could do these things, then you wouldn't do them, and there would be no need for me to tell you not to. And, if you're anything like me, you might be a very curious person. So when someone says, "Hey, don't do that!", you might think, "Hmm... but what happens if I do?" and then go do it just to see what happens. On the other hand, if I don't share my "Never Do This!" list you may stumble upon these things and do them without realizing the implications. Without further ado, I present Melissa's Never Do This List: 1. Never modify code on the Code tab of a job or transformation. What are you talking about - I've never heard of this? If you look at an open job, normally you'll be looking at the Diagram tab. There are three other tabs, too: Code, Log, and Output. If you look at the Code tab you will see all the code automatically generated by DI Studio for the job. And at the very top there's a drop-down menu for the Code generation mode. By default it is "Automatic", but you could change it to "User Written Body" or "All User Written", and then you would be able to modify the SAS code on this tab. Most transformations also have a Code tab with a similar ability to change the Code generation mode. Why? What bad things might happen? Once you change the Code generation mode to anything other than Automatic, the job no longer pays any attention to what you might do in the GUI on the Diagram tab. It only runs the code that is on that Code tab. If you change something on the Diagram, you will not see that reflected when the job runs. This can be very confusing if you don't understand how this works or if another user modifies your job without knowing it was on user-written mode. It also completely defeats the purpose of using CDI. CDI automatically generates code; that's part of the core of this product. If you go into that code and tweak it, you're no longer using the product in its intended way. Can I undo it if I accidentally did this already? Yes! The fantastic news is that all you have to do is go back to the Code tab and change the Code generation mode back to "Automatic". If you've made changes on the Diagram tab while the mode was User Written, the newly-auto-generated code will pick it up. So, thankfully, this is easily fixed. (Do keep in mind that you will also immediately lose any code you may have written while in User Written mode; be sure to copy and paste it elsewhere if it's something you need to keep.) What other way could I get my need met? If there's something you need the job to do that it's not doing, there are other options. First, ask for help. Maybe you just don't know how to get it to work the way you're wanting. Otherwise, you might need a custom transformation to be able to repeat a programming task that DI Studio can't handle with its built in transformations. As a last resort you could use a User Written Code transformation if you truly need a one-off thing that can not be done by DI Studio's other transformations and you never need to repeat. That's the only appropriate place for hand-writing code. 2. Never modify permission settings on the Authorization tab for an object inside the CDI application. What are you talking about - I've never heard of this? If you look at the Properties of pretty much any object within CDI, you will see there is an Authorization tab. Listed on the tab is every group or user who has specific permissions defined. Selecting one of these groups or users will show you the permissions they have on the bottom half of the window. If you have ReadMetadata permission to the object, you could modify those permissions settings on the object. Why? What bad things might happen? Chances are, someone in your organization has put some serious thought and planning into the permissions model in your CDI environment. If you go changing it here, you could make a big mess of that permissions model. You could deny people access to objects they should have access to, grant access to people who shouldn't have access, and create serious confusion for the administrators who are responsible for the permissions model. You could even accidentally deny yourself access to objects. This could have further implications for objects that depend on each other for access. If you denied access to a user for all the source data in a study, when they open a job in that study, all of the source data would appear missing from the job to them, and they will likely have no idea why. The job doesn't give much helpful information other than to say that the job was modified since it was last opened, and appears unsaved. If the user then saves that job, the source tables will truly be removed from the job for everyone. What a mess! Can I undo it if I accidentally did this already? Probably, but it could be messy and you might not be able to do it on your own. The best bet is to get in touch with the administrator who is responsible for the permissions model so that they can take charge of getting the permissions properly reset. There is a utility they can use that can show all of the explicit (non-inherited) permissions throughout the entire system, which can help them verify that the actual permissions are back in line with the permissions model. If you've made a lot of changes, it could be complicated and time-consuming. There is also a difference between permissions set explicitly, inherited, or controlled by an Access Control Template, and you may not know which of those are supposed to be used on the object. I definitely encourage you to reach out to your administrator if this happens, and don't try to fix it on your own without letting them know about the issue. What other way could I get my need met? If you feel like the permissions or access are not correct for an object - whether it's a study, folder, table, domain, or anything else - find out who is responsible for the permissions model in your organization and talk to them. They can investigate your concern and fix it or explain to you why the settings are the way they are. If your organization hasn't put a strong permissions model into place, think about doing so. If you need help, reach out to the SAS Technical Consultant working with your company. If you don't have one assigned, reach out to us here on this community and I'm sure we can help. What other things would you put on the "Never Do This!" list? Please share!
... View more