I am writing some code that will update the reference of the Business Units after the deployment of a new solution.
After a solution import all the references point to the Dev's Business Unit Guid, so, for instance, every view that refers to them is empty.
Manually updating those references is time consuming and boring. That's why I am writing some code that does the trick.
The code works, but it would be much better if I could add it inside a Custom Workflow Activity or a Plugin and have them run after every solution import automatically.
Is it possible or am I just daydreaming?
There is an Import and ImportAll message you can register your plugins on, however I have never used them so I'm not sure how they work.
I have registered plugins on Publish and PublishAll messages before. You can use those messages and they will run after you publish an entity/resource or publish all the changes respectively.
Related
How often is there a check on changes to the source data for the hook to trigger?
We've only managed to get it to trigger automatically / instantly once.
We've tried deleting and reconnecting the source, trying different sources and making new projects.
Sometimes, it just doesn't trigger at all.
Anything that might shed light would be a great help.
The frequency of source data check in Supernova Hooks varies.
But if you're having trouble with the hook triggering once or not at all, here's what you can check:
Double-check that the hook is set up and configured to trigger based
on the changes you want to see.
Make sure there aren't any network/firewall blocks preventing the
hook from triggering.
Check if the source data is being updated correctly and if those
changes are reflected in the hook.
If all else fails, hit up the Supernova support team for help.
And, don't forget, the issue might be with Figma, not Supernova. So, check their docs and support as well.
So I am getting confused with what is the right approach to implementing code that fires on a scheduled bases within azure.
Originally we were using a standard console app that would be put in the webjob folder on deployment. I found this a bit noddy as we had logic looping and waiting for the right time to fire.
I then tried the azure webjob package https://github.com/Azure/azure-webjobs-sdk-extensions, but see this has gone quiet and the master branch is currently broken! I like because it has a CRON type approach with a function.cs, but now not sure if this is being maintained.
So do people have a preference on how a background process would run, e.g. a scheduled task that would run at 2am every day against a database?
Too much choice and not enough consensus on what the right way is?
Much appreciated in advance
I can think of three options, all of which are valid and can suit your needs. Which one to choose in the end comes down to your requirement specifics and your technical expertise.
WebJobs. These are the most powerful and most difficult to build and maintain. You typically use a dedicated project template in Visual Studio to author these. You can ignore that GitHub link - that's not what you need. Make sure you have the Azure workload enabled in Visual Studio and create a WebJob project.
Azure Functions. These are a more lightweight alternative to WebJobs. There is Visual Studio tooling available for this as well but you also have the option of writing your code directly in the portal. Azure Functions will time out after some period of time, so if your job runs more more than a minute or two this might not be the best option.
Logic Apps. This is more of a power user tool with an easy to use (debatable) designer interface. But it's also incredibly powerful and you can call WebJobs or Functions if you need to from a Logic App.
I could add links but I'm sure you could find them easily enough.
For what I can understand one can build Logic Apps with Terraform. However, the docs are still not very good, and it looks like this feature is pretty new.
What are the limitations when it comes to TF and Azure Logic Apps? Are there any?
I want to build a two apps, one that is triggered every month and another that is triggered by a https request. I want these then to run two python scripts, and I want the later one to return the result from this script to the client that called the https.
Is this possible to automate in Terraform? At this moment, there are very little examples and documentation on this. Any comment or tip is helpful and greeted with open arms!
You can create a blank Logic App instance through Terrform (TF). But, if you want to add triggers and actions, I wouldn't recommend using TF at all, as of the provider version of 1.20.0.
TF lacks document around parameters. As you know there are two parameters properties – right under the properties property and right under the definitions property. This document states parameters but it doesn't clearly say which one. I'm guessing this refers to the one under the definitions property, but it actually doesn't work – throws Invalid Template error without enough explanation.
UPDATE: I just reverse engineered by importing a Logic App instance using terraform import. The parameters is actually pointing to the one under the properties property. However, it still doesn't work as the Logic App's parameter value can be anything – object, string, integer, etc, while TF's parameter expects string only. Also, there is no way to create parameters under the definitions property.
TF only supports two triggers – HTTP trigger and Timer trigger. All other triggers should use the azurerm_logic_app_trigger_custom resource, but it requires the body part to manually write a JSON object or import from a file, which can't be parameterised through variables or locals.
TF only supports one action – HTTP action. All other actions should use the azurerm_logic_app_action_custom resource, but, like the same issue above, it's not that useful.
In conclusion, TF lacks supports parameters, triggers and actions. So, unless you just create a blank Logic App instance, TF wouldn't be an option for Logic Apps. If you still want to create a blank Logic App instance with TF, then I would recommend this approach using Azure PowerShell or Azure CLI.
For clarity, you don't use Terraform to create LogicApps. LogicApps are designed in either the Portal or Visual Studio.
Terraform is a deployment/management tool. You can almost surely deploy your LogicApps, and other resources, with Terraform, but they're are already created.
isn't the point of terraform to stand up resources across various environments just by passing in -var environment=qa to create a qa instance of the logic app? prod? uat? marcplaypen? I was hoping to use terraform import to create the terraform file, then create multiple versions of it. I can do it, but not with any parameters, which breaks one of my 'actions'.
I was using a combo of terraform import and logic app code view. most of my actions are pretty much a combo of copying the json block for each action, and modifying based on the first entry of the 'body' of the action generated from terraform import.
Then setting up the dependencies manually based off of runAfter, which tells me what an action is dependent on.
but, it fails on parameters, complaining there's only these declared parameters for my definition are ''.'
I have an app that I have been working on and I did a bunch of changes and then realized later I should have been adding versioning to the Core Data model. So I'm trying to go back and do that now.
Basic information:
I think everything I've done would fall under the lightweight migration feature.
I'm using git
I already have the app in user's hands
My question is: what is the easiest way to do this?
Since I'm using git, could I simply checkout the data model from when I submitted it to apple, create a new version for it, and add my changes? My main fear with this idea is that my project.pbxproj file would be incorrect. Would this an issue? Is there a way to get around this?
IF I could do this, would I need to recreate my class files or would that be ok (assuming I get it back to being identical to what I currently have).
IF I CAN'T do this, then what can I do? If its a matter of starting from the last version I pushed to Apple and applying changes I guess I should look into doing it with git rebase, right?
This has nothing to do with git.
You need to create a new version of your app, provide the new data model, set it for lightweight migration and then release it as an update. Core Data will basically assume that any model without version info is version zero and attempt a migration to the new version.
When the user downloads the update, the automatic migration will trigger the first time the app runs.
Creating a new version means nothing more than changing the version number in the project info. When submitted, that will trigger the upgrade and the migration.
I've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!