There’s more to writing a good Product Pack for Tachyon than having a great idea and being able to implement it technically.
Here’s the TLDR version:
Tip #1: Use Tachyon SCALE language methods whenever possible when writing instructions.
Tip #2: Think about the importance and order of your columns. You can set this in <SchemaJson> in the XML file.
Tip #3: Use icons in your Product Packs, it helps them stand out in the Tachyon Exchange and the Product Pack listing.
Tip #4: Use different phrases to describe your instruction in the readable payload and instruction description.
Tip #5: List the columns you return in the description.
Tip #6: Re-use existing categories where possible, it makes everything neater.
Here’s the full blog, explaining why and how for the items above…
First off, let’s look at the multiple functions that Product Packs serve:
- Most obviously, they facilitate the encapsulation of a specific script or method of doing something(s) technical
- They enable Tachyon users to search for and find functions relating to specific keywords
Number #2 above is at least as important as #1. If you have written some amazing functions as Tachyon Instructions and encapsulated them into Product Packs, that won’t help if no-one can find them when they are needed.
Let’s take an example of a pre-existing instruction, to list running processes. As you can see below – it returns the Account Name, Process ID, Parent Process ID, Startup Time, Command Line and Executable.
This is a solid set of data. Let’s look at how it’s built. We can download the Product Pack (from Tachyon Exchange or from the Product Pack listing page in Tachyon itself). From there, we can open the Tachyon.ProductPack.Manifest.xml file to see how it’s built – here’s the XML from that instruction:
We can see in <Payload> that this instruction uses the Tachyon SCALE language to get the agents to run OperatingSystem.GetProcesses();. That’s smart, as SCALE instructions are cross platform. This instruction will work on Windows, Unix, Linux, Mac and Android endpoints without needing to be changed in any way.
The author could have performed the same function many ways, but if they had used NativeServices.RunWmiQuery() to pull back the data it would only have run on Windows (WMI), if they had used NativeServices.RunCommand() to run an OS native command they would have to write the same logic multiple different ways to get it to work on Windows and Linux and Mac and Unix and Android, etc.
Tip #1: Whenever possible, use the SCALE language to write your instructions.
The <SchemaJson> part of the XML defines the display order of the columns. When I ran the instruction, it struck me as odd that the Executable name was the last, rather than the first column. This is key data.
Tip #2: Think about the importance and order of your columns. You can set this in <SchemaJson> in the XML file.
Now, let’s look at the Product Pack the instruction is part of:
Tip #3: Use icons in your Product Packs, it helps them stand out in the Tachyon Exchange and the Product Pack listing.
Whoever built the Product Pack put in a nice icon, that’s always good. There are 3 instructions in the pack, all related to the same thing (processes in this case), that’s also good. That’s where the good ends.
Remember that different people use different phraseology and wording to explain (and to search for) things.
I often had difficulty when trying to list processes as I’d avoid using “process” to find the instruction because several instructions relate to “Processor” as well as to “Process” – so it’s a long list. I started with “list” but “list” isn’t mentioned in the instruction name or description. The author used the word “Get” twice instead.
Tip #4: Use different phrases to describe your instruction in the readable payload and instruction description.
For example, if your instruction is about active network connections to an IP Address – use the word “live” in your description and maybe the word “now” as well as “active”. Network, IP Address, Port and TCP should all appear somewhere in your description.
As we can see in the first image, this returns Command Line and Account Name and other related data. If a user typed in “Command Line” they wouldn’t see this instruction come up.
Tip #5: List the columns you return in the description. That way, whenever a user types in anything related to your instruction, the instruction will be listed.
Last but not least, think of your Category for the instructions in the Product Pack. Here’s a good example of a category gone wrong:
There are several things wrong here. OperatingSystems is one word – this typo has put the first instruction into a Category of its own, as opposed to the “Operating System” category (below) which already has 3 other instructions in it.
Tip #6: Re-use existing categories where possible, it makes everything neater.
Our “Get processes” instruction is in a category of its own, called “Processes”. I think it can live in Operating System category rather than creating a new one…
Let’s re-work the instructions in this Product Pack to make them more user-friendly. Reviewing the tips as they apply to this example:
Tip #1: Use Tachyon SCALE language methods whenever possible when writing instructions.
Check – we’re all good here.
Tip #2: Think about the importance and order of your columns. You can set this in <SchemaJson> in the XML file.
We should review this. If I change:
To:
Then we’re good here. Remember to watch the commas (if you just shuffle the items, you may have a trailing comma on the last one and an earlier item with no comma…
Tip #3: Use icons in your packs, it helps them stand out in the Tachyon Exchange and the Product Pack listing.
Already taken care of in this case.
Tip #4: Use different phrases to describe your instruction in the readable payload and instruction description.
Right now here’s how this looks in XML:
ReadablePayload=”Get processes”
Description=”Get all executing processes”
I think we can do better. Updated to:
ReadablePayload=”List running processes”
Description=”Returns a list of live, executing processes running now. Provides the Executable Name, Command Line, Startup Time, Account Name, Process ID (PID) and the PID of the Parent Process (ParentProcessId).”
Tip #5: List the columns you return in the description.
Now taken care of in the new description above.
Tip #6: Re-use existing categories where possible, it makes everything neater.
Category=”Processes” becomes Category=”Operating System” and we’re done.
All we do now is zip up the new XML and upload it to Tachyon with a drag and drop.
And voila! Our new, improved Product Pack is ready to be used!
Need more? You can find Product Packs in the Tachyon Exchange. Looking at how others have assembled their Product Packs is always a good way to learn more.
If you have any questions, you can always contact us to speak with a specialist.
This article deals with raw XML quite a lot. There are other approaches, like the Tachyon Product Pack Editor. The editor and the Tachyon Instruction Management Studio (TIMS) will be merging in the near future – removing the need to get down and dirty with the XML at all. For now, I think it’s good to look at the XML proper, see how the bones look. I hope you found this How To post useful.
