Hi SCA Devs, I'm running 2020.1 and I want to extend the standard Case modules with a few client and server side enhancements (eg: using my own HTML cleaning function, pulling additional fields and allowing the type filter to be a multi-select). As of 2019.2 the cases module has been transitioned to SuiteScript 2.0, so my usual method of using

_.extend(CaseModel, { ... })

does not appear to be possible. In SuiteAnswers 'Commerce Migration to SuiteScript 2.0' (https://netsuite.custhelp.com/app/answers/detail/a_id/92119) I also noticed there is a note that says:

if you are developing extensions, attempts to import or include migrated modules in your customization will produce runtime errors.

Does this mean that there is no way to extend the new 2.0 modules? Is there any documentation for making changes to 2.0 scripts? At this point the only way forward I can see might be to revert to making changes directly to the core files - which I'm not keen to do. I'm open to suggestions or experience others have on this matter.

Hey. So, yes, that sort of customisation is no longer supported, partly because the module you require is no longer in use and also because of the change in architecture. Your options going forward kinda look like this: 1. Create your own case functionality (for example copying and replacing/overriding the existing TypeScript files) 2. Do what you can with frontend customisations, perhaps using additional services to get/update your case records as appropriate 3. Restore the old SuiteScript 1.0 functionality (which is still included in the folder) and work with that instead. You will need to update the distro.json file to include it. You can then continue to do customisations to that

Hey @Steve Goldberg, thanks for getting back to me. In the end I chose option 4, where I copied the original SS2.0 Case.Handler.ts file into another folder as a master copy and then made my changes directly to the Case.Handler.ts file. Far from best practice I realise, but the quickest way to achieve what I needed. I'm quite concerned in light of this though that as the migration to SS2.0 continues making enhancements to existing SCA features will get a whole lot harder. I figure this is helpful on the NetSuite side to: 1. Lock down core parts of the platform as SCS becomes more available (without these changes SCS would offer little difference to SCA for an experienced SCA developer) 2. Streamline SCA Support as it makes it harder for customisations in SCA to break standard bits of functionality But I'm really worried from a developer perspective, that with these migrations, if new avenues of customisation don't become available, then simple customisations like what I'm doing here become huge customisations (without going against best practice) where we have to rebuild a module from scratch just so we can add an additional field. Do you know of (and can you comment on) future plans for SS2.0 and customisations to core SCA? This is the biggest shift for the platform since its inception and it makes me quite nervous about future projects on future releases of SCA, where even more code is locked down.

Option 4 was implicit, as I didn't want to recommend it 🙂

Thanks for your response Steve! I look forward to seeing more about those new ways to customise things. I can definitely see that it will make the platform as a whole much better for development, but a bit tricky when in the limbo of the two systems. In the meantime I'll have to look further into how to revert back to SS1.0 using the distro for future changes. 🙂

@Harley, I have run into a similar problem that you faced 10 months ago where you needed to customize the Case module, but in my case, I need to customize the TransactionHistory module. Did you figure out how to override an SS2.0 core javascript/typescript file? I haven’t found a way to do it, like you do for traditional SCA using the ns.package.json directive. Did you figure out how revert back to using the SS1.0 version of a module? When I examine the distro.json, I don’t find much that references the SS2.0 files. So far, I have found very little on how to customize existing SCA core SS2.0 modules. I’ll keep searching. Please help if you can. Thanks.

Hi @Keith Fetterman, I didn't end up pursuing changing the distro. In the end my changes were made in a very bad practice way, that I would be hesitant to recommend using. I only pursued it because it was an internal project, not for a client so we were more in control of the risk. NetSuite has no documentation on making changes to the SS2.0 files as this type of customisation is not supported and is not best practice, so make these changes at your own risk and make sure you know that if you have any issues, you'll have to resolve them yourself - NetSuite won't help. I ended up creating a backup copy of the 'Backend' folder in the SCA Core called 'Backend_Master' and copied the files I wanted to update into this folder (using the same folder structure as the Backend folder. Then I directly edited the original files in the Backend folder. This way when I deployed the updated core files were used for the SS2.0 server code, but I had backups of the originals in case I needed to revert or to use as a reference in future if we upgrade SCA versions. I hope this helps!

@Harley thanks and it does help in that I’m not loosing my mind. I have been unable to find a way to use any of the best practices that NetSuite recommended over the years for the SCA SS1.0 customizations. To make sure I have it right, you edited the original files in place, but before you did the changes you made backup copies and placed them under the “Backend_Master” folder using the same folder structure. I am not sure there is any other way. The distro.json file enabled us to add additional dependencies that when loaded replaced the original prototype methods. I have yet to find a configuration file that does something similar for SS2.0. As far as I can tell, it’s all magic. 🙂 Thanks

@Keith Fetterman yep that's correct. I would have rathered leave the originals where they were and create an overrides folder, but I also had issues understanding how they were referenced via the distro, so went with this method instead.

@Keith Fetterman @Harley When it comes to customising SS 2.0 modules, you basically have three options: 1. Implement your own, complete versions of the modules you wish to customise 2. Do as much as possible with frontend customisations and custom services (ie that leaves core modules untouched) 3. Restore the SuiteScript 1.0 modules, which is still present in the core code, by modifying the distro.json file If you really want/need to change what some SS 2.0 module does, then yes you will need to do option 1. The way Harley has done is OK, but so is creating a clone and updating the distro file to point to the new file's locations. The main reason why we discourage people editing for core files directly in SCA is because it makes it hard to transport those customisations to new versions.

@Steve Goldberg thank you for confirming our assessment on the ability to customize SS 2.0. Do you know if there are plans to provide a better structure for customizing core SS 2.0 modules so we can use best practices to limit the impact of the customizations, similar to what NetSuite recommended for earlier releases, like Kilimanjaro? In regards to “Restore the SuiteScript 1.0 modules, which is still present in the core code, by modifying the distro.json file”, do you have an example you can share? When I review the distro.json, I haven’t been able to figure out how the SS 2.0 services are configured so that requests are sent to the SS 2.0 services instead of the SS 1.0 services.

Do you know if there are plans to provide a better structure for customizing core SS 2.0 modules

I can't comment on future plans. My vague response is that the approaches I laid above are the ones you should focus on.

Do you have an example you can share?

I do not, as it's not something I've attempted myself. However, you should take a look at what's going on in the Advanced > SCA > SuiteScript > SCA.js file. My understanding is that rather than specifying all the modules in the distro.json that you want to exported to the ssp_libraries.js library file, they are listed in SCA.js. You could probably remove the modules from the Backend folder and then 'restore' the SS 1.0 versions to SCA.js.

@Steve Goldberg, thank you. I really appreciate it. This helps a lot. 🙂

Both -- I've had a conversation with the tech writers and they agree we should add documentation around this. If you could give me some use cases you would want covered, that would be great. So far, I can think of: 1. Adding an entirely new module and 'hooking' it up to the rest of the application 2. Modifying existing functionality, such as adding a new field to the Case form/functionality 3. Interacting with the SuiteScript 2.0 files 4. 'Restoring' SS 1.0 versions of modules