rpatrick00
Contributor
Joined 6 years ago
User Profile
User Widgets
Contributions
Re: Custom Snap Pack versioning is broken?
@ptaylor thanks. The other clue that I can give you is that if I change the new version numbers from 2 back to 1 and redeploy like this, everything works fine. I know the new version is picking up the new Account version because I have extra data in the new account version that the snaps depend on for “suggestions” and the suggestions are working in this configuration. If I clear out everything and switch the version numbers back to 2, it doesn’t work.1.5KViews0likes1CommentRe: Custom Snap Pack versioning is broken?
@ptaylor here is what I have found: I restarted by two groundplex servers and verified that no versions of the snaps are downloaded to either server. I have version 1_47 deployed at the global shared level and 2_5 deployed at projects/Robert Patrick I created a new pipeline in projects/Robert Patrick I added a custom snap to the pipeline. I created an account in projects/Robert Patrick and validated it I configured the rest of the snap and added a JSONGenerator and Mapper I still get the NullPointerException at line 78 in OdysseyApiAccount When I look at the groundplexes, I see both 1_47 and 2_5 have been downloaded even though I am pretty sure that I am the only one using it right now…1.5KViews0likes1CommentRe: Custom Snap Pack versioning is broken?
@ptaylor I am not sure what to say but I am seeing a problem. In my release 1 branch (the one deployed in the global shared folder), line 78 of OdysseyApiAccount looks like this: if (String.class.isAssignableFrom(valueObj.getClass())) { In version 2 of the OdysseyApiAccount, line 78 looks like this: private static final String PASSWORD_LABEL = "Password"; When I create the pipeline in my projects/Robert Patrick folder (where V2 of the snap is deployed), I am getting the following NullPointerException. Pretty sure this proves that Version 1 of the Account class is being used…1.5KViews0likes1CommentJTest and delayed Property evaluation expressions
I have a pretty simple snap that takes an input payload and performs an operation the payload, starting at a node specified using a “mapping root” property exactly like the Mapper snap. The snap works fine when testing it manually in the UI. I am trying to use JTest to create unit tests for this snap but when I specify the value for the mapping root in the properties file, the code is getting the literal string instead of the Map<String, Object> of the node specified. My property file looks like this: { "settings": { "mappingRoot": { "value": "$field2" } } } In my custom snap, my defineProperties() method does this: propertyBuilder.describe(MAPPING_ROOT_PROPERTY, MAPPING_ROOT_LABEL, MAPPING_ROOT_DESCRIPTION) .type(SnapType.STRING) .expression(SnapProperty.DecoratorType.OFFERS_SCHEMA) .expression(SnapProperty.DecoratorType.ACCEPTS_SCHEMA) .expression(SnapProperty.DecoratorType.ENABLED_EXPRESSION) .required() .defaultValue(MAPPING_ROOT_DEFAULT_VALUE) .add(); My configure() method does this (mappingRootProperty is of type ExpressionProperty): mappingRootProperty = propertyValues.getAsExpression(MAPPING_ROOT_PROPERTY); And my process() method does this (mappingRoot is of type Object): mappingRoot = mappingRootProperty.eval(document); When run in the UI, mapping root is a Map<String, Object> containing the subtree of the payload assigned to field2. In JTest, mappingRoot is the String “$field2”. What am I doing wrong? Is this a limitation of the JTest framework?1.5KViews0likes0CommentsJTest hijacks URLConnection so it is impossible to build integration tests
I was very hopeful that I could use the SnapLogic JTest framework to build actual integration tests for my custom snap pack. Unfortunately, JTest is mocking the URLConnection in such a way where my custom snaps’ SOAP calls are failing. Sigh… [ERROR] getUserID_ReturnsExpectedValue(com.tylertech.courtsandjustice.snaplogic.OdysseyApiExecutionSyncXmlTest) Time elapsed: 0.059 s <<< ERROR! com.snaplogic.api.ConfigurationException: Getting Odyssey Release Level from Odyssey Site QA-2018-2-MEREADY failed: Failed to call SOAP service: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed com.snaplogic.api.ExecutionException: Failed to call SOAP service: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed at com.tylertech.courtsandjustice.snaplogic.OdysseyApiExecutionSyncXmlTest.getUserID_ReturnsExpectedValue(OdysseyApiExecutionSyncXmlTest.java:33) Caused by: com.snaplogic.api.ExecutionException: Failed to call SOAP service: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed at com.tylertech.courtsandjustice.snaplogic.OdysseyApiExecutionSyncXmlTest.getUserID_ReturnsExpectedValue(OdysseyApiExecutionSyncXmlTest.java:33) Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed at com.tylertech.courtsandjustice.snaplogic.OdysseyApiExecutionSyncXmlTest.getUserID_ReturnsExpectedValue(OdysseyApiExecutionSyncXmlTest.java:33) Caused by: com.sun.xml.messaging.saaj.SOAPExceptionImpl: Message send failed at com.tylertech.courtsandjustice.snaplogic.OdysseyApiExecutionSyncXmlTest.getUserID_ReturnsExpectedValue(OdysseyApiExecutionSyncXmlTest.java:33) Caused by: java.lang.ClassCastException: com.snaplogic.snap.test.harness.UrlStreamFactoryImpl$MockUrlConnection cannot be cast to java.net.HttpURLConnection at com.tylertech.courtsandjustice.snaplogic.OdysseyApiExecutionSyncXmlTest.getUserID_ReturnsExpectedValue(OdysseyApiExecutionSyncXmlTest.java:33)2.5KViews0likes1CommentRe: Why does the Account connect() method return a string?
In my case, “connect” doesn’t actually have any semantic meaning for my custom snaps (since they are sending custom SOAP messages to our legacy system) so I am using connect() to validate the connectivity and credential information used to make a SOAP call (by making a SOAP call). Somehow, I got the idea that I could influence the message that pops up in the UI using the message returned by the connect() method. Clearly, that idea was wrong…2.2KViews0likes0Comments