API & PowerShell

It has long been a goal of us here to allow AppTracker to be used as a platform, our API is a big step towards that goal. Using our API developers and scripters can build extensions to AppTracker bespoke to their business requirements.

AppTracker’s API is a soap based web service that can be accessed from PowerShell, Excel and traditional desktop applications. The API uses AppTracker’s role based security and every call is checked and validated.

Example Scenarios:

  • Custom Reports – Create in-depth excel reports with colours, conditions, charts and more.
  • Automate Tasks – Documentation, group membership, copy files and folders etc.
  • AD Integration – Add users to groups, create users in AT from AD group membership.

  • SCCM Integration – Create packages and collections in SCCM from AppTracker
  • Capture Events – App Raised , Processes Changed, UAT’s signed off etc.


PowerShell Module

To make accessing the API even easier we have created a PowerShell module of over 90 Cmdlets!

Example Cmdlets:

  • Get-ATAllApplications
  • Add-ATNewApplication
  • Add-ATApplicationDependencies
  • Save-ATApplication
  • Search-ATApplicationsByProcess
  • Get-UserMigrationsRequestingAnApplication
  • Get-ATAllUserMigrations
  • Save-ATUserMigration
  • Get-ATUserMigrationDataMiningReport
  • Get-ATApplicationDataMiningReport
  • Search-ATDeploymentUnitsByDateRange

AppTracker API & SCCM

I have been asked a lot recently about integrating AppTracker with SCCM. “Is it possible to read applications from AppTracker and use them to create SCCM Packages and Programs?” ...yes it is!AppTracker exposes a webservice API that customers can write scripts against quite easily.

To demonstrate just how easy it is I created a little video.(read on for an explanation of the video)

Let me explain what is happening…

I have a folder of executables that contains an xml file describing the applications I want to import. The xml file has some basic properties such as AppName, Vendor, Version and the path to setup.exe. The PowerShell script reads the applications from this xml file, it creates a folder structure [server]\[Vendor]\[Application]\[Version] and copies the installation files to the new folder.

After that it connects to the API and uses the “CreateApplication” method to raise the three new applications. It then uses the “AddApplicationNote” method to add a note to the new application and finally it uses the “SaveDiscoveryQuestion” method to add some discovery information such as the path to the source files.

Now that we have three new applications sitting in the “Discovery” process it’s time to move them to the “Packaging” process. We use “GetApplicationsInProcess” to get all of our “Discovery” applications from the API we can then use “MoveApplicationProcess” to move them on to “Packaging”.

Finally I create the SCCM objects, again I use “GetApplicationsInProcess” to retrieve the applications I want to publish. I use a mixture of PowerShell and WMI along with my retrieved application info to create the SCCM packages and programs. I then read the new Package ID from SCCM and write this information back to AppTracker using “SaveDiscoveryQuestion”. It is as easy as that!

I have now…

  1. Created three new applications in AppTracker from an xml source file.
  2. Moved the applications to a different process.
  3. Added new notes and discovery data.
  4. Created SCCM Packages & Programs.
  5. Saved the results back to AppTracker for reporting on later.

All via the API without ever needing to use the AppTracker client.

Be sure to keep an eye out for more posts on our API; with a little PowerShell and the AppTracker API you can automate almost anything in AppTracker.