I created an Agent Type and specified the property of "Use in flowcharts as: Resource Unit".
I created a variable called "Location" of type double.
In a release block, in the "On release" field, when I write unit.Location, Location variable is not identified and I get an error.
How to access variables from the resource agent unit in a seize/release block?
Thank you.
You can always typecast (i.e. enforce) it using ((MyAgentType)unit).Location
However, you must make sure that all resource units being released in that Release block are of that MyAgentType type, else you will get a runtime error.
PS: Java convention has variable names in lower case, best keep those ;)
Related
I am using AnyLogic 8 University 8.7.0 version and doing Agent Based Modelling. I have created a ResourcePool of Auto agents and I want to store the initial locations of autos (GISPoints) in a variable. Using the unit.getHomeLocation() method is giving me the error: "The method getHomeLocation() is undefined for the type Auto". Here, "unit" is the name of ResourcePool unit of the type Auto.
Any workaround for this will be really helpful. Thanks.
Go to your project browser, click on the agent "Auto". In its properties, under the tab Agent in flowcharts make sure Use in flowcharts as: is specified as "Resource Unit".
Let me know if this resolves it.
I built a custom block that, among other things, tells the resource entering portIn of the block to move to the resource's seizing unit. I use a moveTo block with the destination node as: (Node)((Cart)agent).getServicedEntity().getNetworkNode(); but I need to know the agent type and cast it into the method. I would like to make this a generic block that can be used in other models and with any Resource Unit.
I've tried using generic parameters in the custom block
then selecting the agent type:
and then trying: (Node)T.getServicedEntity().getNetworkNode(); but this results in compiling error: The method getServicedEntity() is undefined for the type T. Is there a way to do what I'm looking to do? I'm fine if the user has to select the agent type using the generic parameter pulldown, but I'd like to avoid having to change the code every time to add in all of the resource types available in the model using the instanceof command and then duplicating the code. Seems inefficient.
Well, your "T" extends Agent, and Agent does not know about getServicedEntity.
What your T extends needs to know it is a resource unit. Easiest solution I can see:
Create a parent class MyResourceUnit (but do not instantiate it)
Make sure it is "used in flowcharts as Resource Unit"
Make all agent types that should ever use your custom block to extend MyResourceUnit
Now in your custom block, you should make T extends MyResourceUnit
The following Patch variable works perfectly when setup using the variables functionality within a Pipeline:
Major = 1
crmRelease = 91
Minor = 0
Patch = $[counter(format('{0}.{1}.{2}', variables['major'], variables['crmRelease'], variables['minor']), 030)
Result (on first run) = 1.91.0.30
However, when moving this to a Variable Group, whilst the Major, CrmRelase, and Minor variables are ok, the Patch variable isn't valid and fails. Must you reference Variable Group variables in a different way?
Must you reference Variable Group variables in a different way?
The issue for Patch does not been parsed is not relevant with the reference way to variable which stored at variable group. It just because the function parse does not supported in Variable group.
For further analysis, here let's do 2 tests(the first one is failed to get Patch value, but the second one can succeed).
One is put all of them into Variable group.
The another is putting Major, crmRelease, Minor into Variable group, but ** ** make Patch in Variables.
Here are their initial logs:
Putting all of them into Variable group:
Only store Patch into Variables, but make others still in Variable group:
You can see, only store Patch in Variables, the function of it can be parsed at compile time. For the one which store at Variable group, our system treat it as a normal value. We does not support the function parse process when it is from Variable group.
To make it not interrupt your build, please make sure the variable which contains the functions in it are located at Variables instead of Variable group.
I have a release pipeline with a variable, but there doesn't seem to be any way to set the value of that variable to something that's evaluated at release time. For example, another variable.
Here's a real example:
All I want to do is set the value of MyExpressionBasedVariable to the value of MyOtherVariable.
All the docs and examples online seem to suggest it's possible, but I can't get it to work. I always end up with the literal string rather than the evaluated value.
I've tried using these different syntaxes:
$(MyOtherVariable)
$[variables['MyOtherVariable']]
${{variables['MyOtherVariable']}}
I've seen that you can define custom tasks to set variable names as part of the pipeline but this seems massively overkill.
Essentially all I want to do is rename a key vault secret to a different variable name for convention-based XML variable replacement in config files.
E.g. I have a secret called this-is-a-secret-name-which-is-a-different-naming-convention-to-my-connectionstrings but I need it in a variable called MySecret-ConnectionString.
How do I use the value of another variable in a release pipeline variable?
How do I use the value of another variable in a release pipeline variable?
As I test, what you set should be work. You can try to follow below steps to check if you still have this issue:
Create a new release pipeline without link any variable group.
Set the Variable like following:
Add a Run Inline Powershell task to output the value of the Variable:
Write-Output 'The value of MyExpressionBasedVariable is $(MyExpressionBasedVariable)'
Write-Output 'The value of $(MyOtherVariable) is $(MyOtherVariable)'
Then we could get the log:
So, what you set should be work, if this still does not work for you, then you need to make sure that the variable you describe in the question is the variable your actual test.
Besides, at this moment, the value of nested variables (like $(TestVar_$(Release.Reason))) are not yet supported in the build/release pipelines, check this thread for some details, so make sure there are no such nested variables in your project.
Hope this helps.
I have a web application that I build and release using TFS. The release definition contains a task group with all the necesarry steps for the deployment of the web application.
What I want to do is to determine a certain value and store it in a variable to use later on in the release proccess in the other release tasks.
At this moment, the first step in de task group is a Powershell task that determines the necessary value and stores it in an environment variable using:
Write-Output ("##vso[task.setvariable variable=MyVar;]$var")
When I use this environment variable in the next Task (Again, a PowerShell task), it runs perfectly as expected using:
Write-Host "Doing stuf for: $env:MyVar"
It's when I want to use the variable as a parameter for (multiple) different task(s) when it gets weird. When the environment variable has no default value, the calculated value from the first PowerShell task is used and all is well. But TFS doesn't like it when environment variables have no default value and forces to provide one before being able to save the release definition again. When I provide a default value, the task that uses the variable as Task parameter uses the default value, instead of the calculated value. I would expect that the calculated value should be used, as the second PowerShell task ensures that the calculated value is properly stored.
So, the symptoms I see:
When not providing a default value, the code in scripts as wel as the task parameters use the calculated value
When providing a default value, the code in scripts use the calculated value and the task parameters use the default value
Is there something I do wrong, or am I using environment variables wrong and should I use a different method?
As I understand it, you want to define your variable in a powershell-task within the task group, but you are also being forced to provide a value in the environment variable, causing the variable sometimes to have the value set in the powershell, sometimes to have the value defined in the environment variable.
The solution is to just provide the name of the environment variable itself, so it always gets overwritten by the value you set in the powershell task.
Source: https://blogs.msdn.microsoft.com/harshillodhi/2016/11/29/vststfs-understanding-task-groups-and-its-various-use-cases-with-setvariable-logging-command/
Under the header "What is a setvariable logging command and how to use it with Task Groups?", three scenario's are referenced. It sounds like the second scenario may fit your needs.