Debugging Javascript - General Guidance

I’m looking for General Guidance, not a solution to a specific problem!

I have a lot of experience programming in server-side languages like C++, C#, T-SQL, PL/SQL, and others… but am very much a newbie at Javascript. (When my employers’ pipelines use a Script snap, we solely use Javascript, not Python nor Ruby.)

How do other Snaplogic users debug the JS in their script snaps?

I’ve been largely just writing the equivalent of “print” statements by creating a debug object or a set of “trace” properties in the document stream. But that’s a rather hamfisted and slow-going method for debugging.

I seem to recall that SnapLogic uses (used?) the Nashorn engine, but now that Snaplexes are on Java 11, is that still true? There’s the “NCDbg” project on GitHub, which provides a debugger for Nashorn that can connect to Visual Studio Code (VSCode) as a front-end… but it can only handle JS atop an underlying Java 8 or 9 JVM. I’m wondering if there is something similar that would match up more closely with the SnapLogic engines and environment.

What do the rest of you do when you want to debug a script snap?

Thanks!

Yes, we still use the Nashorn engine for JavaScript. It’s deprecated but still present in Java 11.

I can’t speak to how anyone debugs their JS scripts.

1 Like

Thanks for the rapid reply!

I’m hoping that a long-term Snaplogic user might chirp up with some phenomenally useful tricks that let me find problem code in our JS snaps and fix it.

For most transformations, the SnapLogic expression language can be used. We support dynamic validations, which enables rapid prototyping and development.

For more complex requirements, a custom Snap can be developed in Java. Full IDE support is possible through debugger support. A custom snap has performance advantages over a Script snap when the document count is large, but the development of the custom snap does require more effort.

For the Script snap, using log statement to debug the script is one approach. Another approach is to develop the script outside of SnapLogic, using the command-line version of the language to test the script and then upload the script into SnapLogic. This works well for Jython, I believe the same approach works for JavaScript.

1 Like

Is there some other kind of logging available in JS besides adding extra “trace” properties to docs in the document stream?

Thanks, AkiDave. I think of the three options you present, only the third pair are viable: logging and/or externally debugging. If I’m troubleshooting someone else’s implementation of XTEA (or something else not built into Snaplogic), for example, I’m not going to be able to break that into expressions in a mapping snap. And I don’t have the budget to sidetrack an entire developer for a while and have them learn to implement a custom debugging snap — we would have done that long ago if we had known that was going to be something we needed.

So I’m hoping that another pipeline developer (customer or SnapLogic) who’s done this can chip in and advise me how to set up an external debugging environment. (This would speed up things for me wonderfully.) I’ve been trying to set up NCDbg and Nashorn atop the same Java 11 distro that we use in the Snaplex, but the documentation is sorely lacking and assumes a lot of infrastructure knowledge that I just don’t have. Instructions like “just run the engine like you normally do and pass the same configuration parameters you used there also over here but with so-and-so modified.” Okay, if I’ve never run the JVM stand alone and also never a JS engine on top of that, and also the debugger components, there is no “usually,” LOL.

@ptaylor or @akidave -

I’ve been able to do a little experimentation using Microsoft Visual Studio Code using its built-in JS debugger. And I think one of my colleagues may be close to getting it to work with NCDbg + Nashorn + Java11 (same JVM distro our GroundPlexes use).

But it requires commenting out a LOT of the SnapLogic infrastructure so that what one is debugging is only marginally like the code that gets executed in the Snap.

In particular, it would be helpful to be able to fake a doc stream, and to be able to instantiate a copy of “impl” and debug the execute method. But that requires fake versions of (input,output,error,log).

Can you please ask around within Development about this? I imagine someone there might have built some scaffolding or a test jig where they could run a script externally with some faked inputs.

For that matter, since we’re exclusively on GroundPlexes, and the WAR files are right there, I imagine there might even be a way to import some of that?

Thanks!!
@ForbinCSD aka JohnB