To celebrate this fantastic day, we are taking our first exciting step to provide you with a developer-focused center of information and exchange within community. We are affectionately calling it the Developer Hub. Additionally, we are also proud to announce the launch of the API developers community group, so please invite your peers and API enthusiasts here. I want to start the trend of welcoming our newest members to the API developers group: @firstname.lastname@example.org@jwakefield@Joshua.Huilar@SR@GeorgeDuckett@AdamT Feel free to introduce yourselves and talk about some of the exciting projects that you are working on using Anaplan APIs.
I've been using Anaplan a little over a year and the API basically since the beginning.
We currently have a little console app written in C# that manages running processes and exports. We have views in SQL Server that match Anaplan import filenames that the actions those processes use. You can tell the console app what processes to run and it will use the API to work out what files to upload from the SQL Server views. It then runs any processes needed. You can also specify any Anaplan extracts you want and it'll extract the data, transforming it as required (composite hierarchy into individual entity keys), inserting it into an automatically created SQL table. Once that's done it'll check the extracted actuals figures and compare to the source data in our data warehouse and warn if there's any discrepancy. Finally, it will extract the model design (line item formulas etc), generate a simple file structure for them then update a Git repository so I can see model design changes over time easily.
Outside of work I've also been playing around with creating a grammar for the Anaplan formula language (initially very simple, so I could format the model design formulas a bit better so Git diffs looked reasonable) but it's expanded into the heart of a chrome extension I've been working on in my spare time. I'd started work on it before the announcement to move to the Monaco editor (a great editor framework!), which I was already using in my extension. Since then I've integrated my enhancements into their new editor. It's very much in alpha as there are some known limitations / quirks, but currently it highlights syntax errors, missing dimension errors, incompatible line item / formula data types and allows you to hover over a line item to see it's data type and dimensions. A couple of examples of how it looks below.
Hover to see dimensions:
Highlight data type errors:
Missing dimension warnings:
All the above are far from perfect; some of the error messages could be better but are a very basic first step. I'm also working on being able to hover over more things with data types (list items, list item properties, functions etc, not just line items), as well as things like function names to get the parameters etc.
Context-aware customised auto-complete for lineitem names / functions / module names etc is also on the list.
This is super cool - I currently am setting up a similar process, but as a Flask Web App hosted on AWS, and using Anaplan as our back-end, where the actions per process are defined. We went down this route as the CloudWorks was a bit limited in inter-model integrations, and also being able to define event-based integrations compared to only scheduled ones.
> generate a simple file structure for them then update a Git repository so I can see model design changes over time easily.
Are you able to share any detail on how you do the transforms? I had thought about doing this, with extracting the model blueprint then doing matching on the combo of module name and line item name with the IDs returned by the transactional API line item endpoint, but hadn't thought of all the edge cases of items being renamed, or otherwise deleted and re-created.
The linter you've created is very innovative as well! If you ever need any alpha/beta testers, you know where to find one.... 🤣
Basically it runs an extract of the module line items using an Anaplan extract (into SQL since I had that already), then I run a query to handle line items inheriting things from the module (applies to mainly). Once that's done it creates folders for modules and normalised json files for line items, with a separate file for a line item's formula (since that's mainly what I want to see changes for, and want formatted nicely). It doesn't handle things like renaming (that'd show up as an add and delete), since I have it generate files based on the names of line items in folders of module names. I find this works well enough for our use case.
Re the linter, once it gets a bit more robust I'll definitely make a dedicated post here for testing and to gather feedback!
Great idea! I also have one that I use fairly extensively. I need to update it with the new ALM APIs, and probably do a bit of cleansing and make sure it has no sensitive information hard-coded in the calls before I can share it. When I get around to it (hopefully soon), I'll create a new topic, and we can discuss if there are any missing ones.