Developer Community | What would you share?

[LeahK]

If you didn't get a chance to watch the Product Keynote at Inspire Europe, you may have missed @AshleyK's exciting announcement of our plans to launch a Developer Community.

"The developer community will serve as a hub for collaboration and discovery, connecting developers all over the world to build exciting new innovations in Alteryx."

Now that we're all up to speed, I wanted to throw a few questions out to the Community, that I hope will initiate some interesting, if not heated, conversations.

Question:

What do you consider "Alteryx Developer" content? What would you share on the Developer Community? 

Does a bad-ass Macro that pushes the limits of what you thought was possible with Alteryx, belong on the developer community?

Please share as much or as little as you like.  We can't wait to hear your thoughts!

[patrick_digan]

I think anything that ends up in the Alteryx toolbar (macros, custom tools, etc.) or part of an Alteryx tool (formula add-ins, etc.) is Alteryx Developer Content. While the CReW macros (@AdamR_AYX) and Omnibus Tools (@jdunkerley79) have really taken off as developer content, I look forward to a developer community that helps many other people showcase their cool work. In particular, there is a lot of great stuff in the public gallery that I hope gets more recognition/attention as part of the developer community.  I think @Ashish is on to something with their idea calling for a more social/engaging public gallery. I think the new developer community will fit that bill!

[jdunkerley79]

I agree with @patrick_digan that anything that ends up 'expanding' the toolset counts as developer content. It's very hard to think where you draw the line on macros. While you might exclude the simplest of simplest ones. Once you start thinking about significantly modifying the XML configuration of tools then this feels very much like development.  From a production perspective, I have always considered Alteryx Workflows and Macros as in the same class as source code - e.g. wanting version controlling and careful testing.

I also agree with @patrick_digan that a place to showcase and better distribute work produced by the wider community would be good. I would love an 'Extensions Marketplace'  where popularity (e.g. number of installs) and reviews would be clearly visible. 

Other content that would be nice is lots of starter guides like you have for the HTML/JS tool and some dedicated Q&A section where more in-depth technical question can be asked and explored.

[Claje]

To me, any kind of sufficiently configurable macro belongs in the developer community - Any process where you are effectively replacing/supplementing the existing toolset of Alteryx should have a place.

A quick example that I built a batch macro for recently was a use case where I needed to load all excel files from a directory, but the files might end up with an extra field here or there, which would cause the Dynamic Input or Data Input tools to skip cases with different fields.

The solution for this was pretty simple - I built a batch macro that reads in filenames from a directory and loads each file - and adds a null value for any field that is missing from file(s).  This batch macro is four tools - Control Parameter, Action, Input Data, Macro Output.

While this is a very basic batch macro, I think it solves a real-world issue that is encountered constantly, and that my baseline example, which supported one file type, could be enhanced to support all of the traditional Alteryx Input Data options, which seems like a great use case for a collaborative development forum.

Additionally, there are a lot of discussions I have read/listened to (particularly between ACEs) where the topic of performant methodologies within Alteryx comes up.  I think that this information is very valuable, but is currently scattered amidst some combinations of presentations, text posts, and hearsay.  Having a dedicated space to discuss "optimal"/performant Alteryx workflow design/solutioning could be really helpful.

[SeanAdams]

:-) Thank you for the question @LeahK!

Developer: Firstly: in my mind, we should draw the distinction between people delivering solutions using the standard Designer capabilities (who are called "Developers" in some places) and people who are developing new kinds of capabilities for the platform as a whole.

Scope:

- Agree with the folk above ( @Claje ; @jdunkerley79 @patrick_digan) that a capable macro which could conceivably be deployed as a generic tool in the product is fair game.   However, I'd say that if people are showcasing stuff like this then they have to be OK that this can get rolled into the product with no Intellectual Property claims.    

- Also agree that additional functions (like @jdunkerley79) has developed should be included

- We always forget the server environment - I'd love to see an active community of developers around the server because that's very poorly supported.   Things like monitoring scripts; governance; cute ways to reindex a server; etc

- Uses of calling Alteryx canvasses through the API embedded in something else

Content:

- Worked examples of Functions; macros; etc.   Again - if you publish it here, you have to be OK that it's now essentially open-source.   Hopefully provided by both the community outside & within Alteryx

- Training & how-to guides - really keen to see something about "how to get started"

- Some mechanism of voting for which pieces of new functionality or macros should become CORE products.   let's be aggressive, and take at least 1 item per month, and actually bake it into the product - that way we know we will grow Alteryx by at least 12 tools per year.

Note: 
While a rich developer community is essential to the growth and innovation of a community - because of our corporate lockdown environment, we cannot download much (or anything) internally that is not part of the core product.   So in many ways, I see the developer community as

a) a way for companies to self-solve for gaps in the Alteryx product

b) a way for Alteryx to identify these gaps, and build them into the core product.

Thanks @LeahK

S

[Hiblet]

TL;DR: I have plugin tools to share but can't find out how to...

I would guess I fall into the Developer Community.  I am a C# coder and I have just started working with Alteryx.  Last week I made a couple of C# plug-in tools, and now I would like to share them, but I do not know how. 

One tool adds a GUID to a record set.  I went looking for a GUID tool and couldn't find one, so I thought that might help someone else one day. 

The other tool takes an XML string and parses it into one-record-per-element records.  It basically does exactly what the JSON Parser does, but for XML, and handles attributes and mixed content.  I don't mean to be rude about the current XML parser, but I know a lot of people struggle with it (I do, for one).

There are a couple of loose ends with the tools. I cannot make the tools appear in the correct tool group, probably because I have got the wrong name for the INI file.  Also, I do not know where the friendly name for the tool is set, and currently the tool appears in Search with it's class name.  Neither are breakers and I can still access and use the tools.  I have a call open with support for this, but if anyone (looking at @jdunkerley79 ...) knows how to tackle these two issues, I would really appreciate the guidance.

There is the ability to share macros and workflows in the gallery, but I can't find a way to share DLL Plug-in tools.  For now, I was thinking of making a blog post in the Engines blog, but that looks like it is curated, I cannot see how to make a post.  I could make a public GitHub repo and link to it, and put the Usage instructions on the ReadMe.

Alteryx might want to curate and quality control plug-in tools.  There might be a standard test set that each tool has to pass before it gets 'certified' by Alteryx.  Or, allow two levels, certified and non-certified?  Blocking creativity might be counter-productive, but badging approved creations seems positive.

[@SeanAdams mentions corporate lockdown, a good point.  A GitHub repo might solve this as the code is text, and can then be read and compiled on site.] 

So, can anyone help me share my plug-ins?  Specifically to reply to @LeahK - I would share a lot of stuff in future, any useful nuggets that improve the quality of life for users.  I would even do requests. 

Steve

[jdunkerley79]

@Hiblet welcome to SDK world...

For GUIDs the in build solution is the formula tool which has a UuidCreate() function.

For the XML Input - I agree and did similar (https://jdunkerley.co.uk/2017/04/24/how-to-create-a-xml-input-tool-with-alteryx-omnibus/). I publish all my stuff on GitHub.

For doing the friendly name and category:

- Category can be done in ini file but is across all tools in the dll

Otherwise add something like:

  <Node MergeId="OmniBus.XmlTools.XmlInput" Description="XML Input">
    <Group>Connectors</Group>
    <Metatag>XML</Metatag>
    <Tooltip>
      <Description>Import XML.</Description>
    </Tooltip>
  </Node>

to the DefaultSettings.xml file in Alteryx folder

Alternatively put an HTML UI on top of it and use the config file :)

Meta data talk here: https://jdunkerley.co.uk/2016/07/29/beyond-alteryx-macros-introduction-to-the-sdk/

@SeanAdams if the github re build works for you should be easy to get OmniBus and Abacus in for you. 

[Hiblet]

@JDunkerley79 Thanks, much appreciated!

I did not spot the UUID function - I will take a look. 

GUID tool was a good exercise, even if it turns out to be utterly pointless :)   I found passing through a record quite difficult, because I could not find a copy function for inbound to outbound records.  I ended up copying each FieldBase, generating an outbound RecordInfo, creating a record from that and setting the fieldBase from string, which seems a bit clumsy.  I have probably missed the simple way to to do it, but I do not have much documentation on data structures and functions other than what Visual Studio exposes.

For the INI file, what are the naming rules?  The DLL is picked up by location in the PlugIns directory, but the docs just say to call your INI file "CustomPlugIn.ini".  The internal setting elements of the INI have no connection to an assembly, so how does the DLL link to the correct custom ini file?  It might be matching assembly name to INI file name, or the name for the IPlugIn class, or the INetPlugIn class, or even the UserControl.  I have tried many combinations and cannot tell if the INI file is being found or not.  I have a call open with Support for this, no worries.

Thanks for the tip on the DefaultSettings.XML file, I have not looked at this, I will do so.

Aside: I think I have found a bug if I use duplicate configuration XML element names in two different plug-in tool assemblies.  Say I have two tools that both use "FieldName" as an element in the config.  This seems to cause an error.  I get around this by using a namespace for the config element ie GuidFieldName and XmlSlammerFieldName.  I can see why this would happen, if the save routine tries to update an element and finds two similarly named elements in the config.

I have read your SDK notes, it was my 'Way In' door.  I would like to write some kind of blog up on "My First C# Tool", but I don't think I can post directly to the Engine blog, it is curated, right? 

I am much obliged to you for your help,

Cheers,

Steve

[jdunkerley79]

The ini files can be named anything. It searches for all dll inside the specified folder:

[Settings]
x64Path=C:\Repos\AlteryxAddIns\AlteryxAddIns\bin\Debug
x86Path=C:\Repos\AlteryxAddIns\AlteryxAddIns\bin\Debug
ToolGroup=OmniBus

I don't think you need the x84Path anymore as no support. The DLL must be compiled in x64 mode.

The designer will load all .Net dlls found within the folders of all the ini and look for classes with an IPlugIn interface. Note this cannot be on a base class (:().

For the engine side, the IPlugIn specifies what should be run. This is done by the EngineSettings element in the XML.

<EngineSettings EngineDll="OmniBus.XmlTools.dll" EngineDllEntryPoint=".Net:OmniBus.XmlTools.XmlInputEngine" />

The DLL name must be unique across all loaded DLLs, and I think they are all loaded into the same AppDomain so expect they need to be Namespace and Class unique. The engine class must be an INetPlugin (though in this case, it can be on a base class)

I got frustrated at the boilerplate and did a load of wrappers for the OmniBus classes. Made building tools a lot quicker :). Happy to show you if you want.

Yes, the Engine blog is protected - I've not got any under my own name on there!

James

[Hiblet]

I feel extremely dim - I can't understand how the INI links to the DLL.  Don't worry, I'll get there eventually, no biggie, I will re-read your notes, I probably just need another coffee...

Any idea who I contact to get a blog entry up? 

Thanks very much for your thorough and considerate replies, hope you have a great weekend.