ddellsperger
Admin
Joined 4 years ago
User Profile
User Widgets
Contributions
Re: not able to get the third party libs in customsnap Snappack
if your directory structure looks like this: snappack ├── lib │ └── commons-logging-1.0.4.jar ├── src │ └── main │ ├── java │ │ └── ...source files │ └── resources └── pom.xml Then, you would need to specify: <library.path>${project.basedir}/../lib</library.path> as the project.basedir points to your src directory.Developing Snaps on Windows via WSL
We recently had a support request received via the support e-mail for snap development and found that the root of the issue (accounts in custom-developed snap packs) was caused by a strange behavior with how Windows (and specifically Windows Subsystem for Linux) sets certain environment variables. I want to highlight the problem, and the final solution if you are developing snap packs on Windows using Windows Subsystem for Linux. First, I want to highlight the portions of the pom file for a snap pack where this comes into play. All of this is happening in the last two plugins for the pom where we're loading the directives file (in your src/main/config folder) to populate runtime properties for the maven antrun plugin to generate a build.properties file (in the target/classes folder) in order to populate certain schema in your bundled snap pack zip file. <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <executions> <execution> <phase>generate-resources</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>src/main/config/directives</file> </files> </configuration> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.8</version> <executions> <execution> <id>generate files</id> <phase>generate-resources</phase> <configuration> <target> <!-- This will add the build number and version in the resources file. Don't change the formatting below. --> <echo file="${project.build.directory}/classes/build.properties"> build_number=${sl_build} snap_pack_version=${VERSION} snap_pack_fqid=${snap}-snap-${VERSION}-${sl_build}.zip snap_pack_url=$SNAP_HOME/${snap}/target/${snap}-build snap_pack_name=${NAME} </echo> </target> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin> I want to explain what these plugins are doing to better understand the what is happening specifically with Windows via Windows Subsystem for Linux. The first plugin (properties-maven-plugin) is loading your directives file (something like below) and converting it into a "properties" file (where the first word is the key the rest of the line is the property value) so that it can be used in downstream plugins and configurations to inject variables into different items. The second plugin (maven-antrun-plugin) is then reading properties (from the environment as well as maven and what we loaded in the first plugin) and then writing a file (in this case the build.properties file in target/classes) with certain values which are coming from pom properties (like ${sl_build} , and ${snap} ) and others are coming from the directives file (like ${VERSION} and ${NAME} ) Example directives file: NAME Snap Pack Name VERSION 1 LANG java ASSET_DIR_PATH /snaplogic/shared For most systems, this has no issue running, in the end the NAME (snap_pack_name in the build.properties) file gets injected into the schema files and that is what powers the connection between accounts and their respective snaps. Windows (and specifically Windows Subsystem for Linux) however throws a bit of a wrinkle into this. Windows loads the hostname of the computer into the %COMPUTERNAME% environment variable (see here) for use in scripts. Windows Subsystem for Linux, however sets this to $NAME which is the cause of the clash that brought me to write up this post. All of the maven plugins will prefer the use of the embedded Environment variable settings over the properties pulled in from any files (so if your machine is setting a NAME environment variable, that will be used over the property in the directives file). The format of the directives file is unable to be changed as it's crucial for the deployment (upload) of the snap pack within your SnapLogic environment. As a result, there are a few ways to override this, but the easiest would be to force a prefix on the environment variables coming through the directives file. To accomplish this (and we will be updating our archetype for the August release with these changes), you'll need to update the properties maven plugin to 1.2.1, this will be present in your properties section within the pom file. <properties-maven-plugin.version>1.2.1</properties-maven-plugin.version> Then you will need to update your last two plugins (listed above) with the following updated settings and configurations: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>properties-maven-plugin</artifactId> <executions> <execution> <phase>generate-resources</phase> <goals> <goal>read-project-properties</goal> </goals> <configuration> <files> <file>src/main/config/directives</file> </files> <keyPrefix>directives.</keyPrefix> </configuration> </execution> </executions> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>3.1.0</version> <executions> <execution> <id>generate files</id> <phase>generate-resources</phase> <configuration> <target> <!-- This will add the build number and version in the resources file. Don't change the formatting below. --> <echo file="${project.build.directory}/classes/build.properties"> build_number=${sl_build} snap_pack_version=${directives.VERSION} snap_pack_fqid=${project.artifactId}-snap-${directives.VERSION}-${sl_build}.zip snap_pack_url=$SNAP_HOME/${project.artifactId}/target/${project.artifactId}-build snap_pack_name=${directives.NAME} </echo> </target> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin> With these changes, leveraging Windows and Windows Subsystem for Linux to build your project will continue to work as expected. Thank you for lending me your eyes and attention to potentially help with the development and deployment of your own custom snap packs, feel free to reach out if there are questions regarding snap development!Re: SFTP Connection and Encryption Algorithms
Unfortunately the SFTP negotiation is a bit cryptic (especially from the dataplane side), the easiest way to figure out specifically what the snap is seeing is to enable the JSCH logging (you'll need to add this to your jcc.jvm_options as well of -DenableJschLogger=True and to then check the log output from the jcc itself those files will contain "JschLogger.java" as the file and will provide the full negotiation details (server and client side). There's also logging in the jcc that indicates what the original pieces were and what the override properties being added were. If you're still facing further issues, please reach out to support they will connect with you to help debug further (and potentially increase the scope to pull in dev as necessary).Re: HTTP Client Snap is converting json object to array while performing POST call
If your api is simply expecting an array of your internal JSON object, you can change the http entity that you're sending (assuming your'e sending a raw http entity using the full document $ ) to [$] and that will wrap your document in an array.Re: OAuth2 account - error 500 on authorization
You should see the Access Token and potentially Access Token Expiration fields visible/populated with something. Depending on if your OAuth2 endpoint supports refresh tokens and/or expiration times for access tokens, what you see might vary, but you should see at least something populated (see below) If you're not seeing data populated there, it likely means there's further issues with auth, you'd have to look into the JCC logs (the logs on the JCC machine) to know for sure what the issue is there, but generally you should be able to make the connection that no errors means authorized.
