nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Questions on Transaction methods

Georg Kandler

Hello everyone,

during the SAF bootcamp, a couple of questions regarding Transaction methods came up.

In the bootcamp, there is an example where we add two transaction methods calculate() and write_file(). This works without problems if implemented as instructed in the bootcamp documentation, that is, calling each of these transaction methods from within the page-callback. However, when I try to call one transaction method from within another transaction method, such as in the following screenshot:

then I get the following error:

The solution definition is invalid: invalid attribute 'write_file' in FourthstepStep.calculate. Please make sure that the field is declared in the step and in the transaction decorating the method. Traceback (most recent call last):
File "C:\ansysdev\initiatives\saf\training2025\my_solution\.venv\lib\site-packages\ansys\saf\glow\_executor\method_runner.py", line 179, in run_method result = self._run_method(
File "C:\ansysdev\initiatives\saf\training2025\my_solution\.venv\lib\site-packages\ansys\saf\glow\_executor\method_runner.py", line 242, in _run_method return transaction_step_method(
File "C:\ansysdev\initiatives\saf\training2025\my_solution\.venv\lib\site-packages\ansys\saf\glow\_core\transaction.py", line 327, in step_method_wrapper result = step_func(**args_for_step_func)
File "C:\ansysdev\initiatives\saf\training2025\my_solution\src\ansys\solutions\my_solution\solution\fourthstep.py", line 41, in calculate self.write_file()
File "C:\ansysdev\initiatives\saf\training2025\my_solution\.venv\lib\site-packages\ansys\saf\glow\_executor\transaction.py", line 280, in __getattr__ raise MalformedSolutionError(
ansys.saf.glow._server.exceptions.MalformedSolutionError: 500: The solution definition is invalid: invalid attribute 'write_file' in FourthstepStep.calculate. Please make sure that the field is declared in the step and in the transaction decorating the method.

Is there a reason why I cannot use a transaction method from within another transaction method? I assume this is by design?

My understanding is that the main purpose of transaction methods is to load data from the project space, (e.g. when opening an old/already solved project) or to transfer data between steps. Is that correct?
What about regular step methods? I successfully added a regular method and invoked it from a transaction method. My observation is that if the step and its fields have been properly instantiated, the regular method also has access to all the fields. But is that "allowed", or is this misuse? Could you comment on that?

Find more posts tagged with

Python

scripting

Solution Developer Community of Practice

Comments

Romain Lejeune

Hi @Georg Kandler !

Yes it's by design indeed: you can't call another transaction from another transaction. This is because transactions are "stateless", they have to know only about what's downloaded there. You can see that as a constraint, but in compensation it allows for scalability.

Let's have a look on the code to understand why. You are calling self.write_file() from calculate() transaction. Now think that calculate() transaction is sent in the cloud: all it'll know is what is "downloaded" in the decorator, i.e. "start", "stop", "num" variables.

When you call self.write() does need to download "samples" though. But in the method space of calculate() transaction, "samples" does not exist, and it can't access it. Now you should understand why this can't be allowed.

PS: I think there are other reasons, like the dependency of states of the variables stored in the step.

Romain Lejeune

Transaction purpose is really to be stateless as explained above, and download/upload only what is required/output in your method.

Transactions can access (multiple) Steps fields indeed.

Steps are there to store/persist those fields inside a project.

Romain Lejeune

You can indeed define regular functions inside a transaction. Like you would define a function inside your function.

I'm not sure if it's a good practice I would say yes if it's clarifying the code.
But if you have lot of logic inside a transaction, you would maybe prefer to store that under the "logic" folder, which is there on that purpose.

Georg Kandler

Yes it's by design indeed: you can't call another transaction from another transaction. This is because transactions are "stateless", they have to know only about what's downloaded there. You can see that as a constraint, but in compensation it allows for scalability.

Let's have a look on the code to understand why. You are calling self.write_file() from calculate() transaction. Now think that calculate() transaction is sent in the cloud: all it'll know is what is "downloaded" in the decorator, i.e. "start", "stop", "num" variables.

When you call self.write() does need to download "samples" though. But in the method space of calculate() transaction, "samples" does not exist, and it can't access it. Now you should understand why this can't be allowed.

PS: I think there are other reasons, like the dependency of states of the variables stored in the step.

Thanks for all the good answers @Romain Lejeune, I am think I am beginning to understand!

Do I understand this correctly: In the above code, self.write_file() would have no access to field "samples", because it has not been uploaded back by the self.calculate() transaction method yet?

In any case I will have to think a bit more about what "method space" means in this context. In the bootcamp there is this image to explain file handling in SAF:

I assume this also applies to handling of the fields?

Georg Kandler

Transaction purpose is really to be stateless as explained above, and download/upload only what is required/output in your method.

Transactions can access (multiple) Steps fields indeed.

Steps are there to store/persist those fields inside a project.

This makes sense - thanks for the clarification!

You can indeed define regular functions inside a transaction. Like you would define a function inside your function.

I'm not sure if it's a good practice I would say yes if it's clarifying the code.
But if you have lot of logic inside a transaction, you would maybe prefer to store that under the "logic" folder, which is there on that purpose.

Thanks @Romain Lejeune ,
I actually meant classic methods, see highlighted example in below screenshot:

I think I am beginning to understand that this is not a good idea, because this method - in the cloud context - might not have access to the "start" field. Is that correct? Why does it still work in my case (is it because everything is local at the moment?)?

Romain Lejeune

@Georg Kandler please find follow-up answers!

Do I understand this correctly: In the above code, self.write_file() would have no access to field "samples", because it has not been uploaded back by the self.calculate() transaction method yet?

Yes indeed, upload is happening at the end. More generically, it's hard to match "download" and "upload" of different transactions, that's why it's not possible.

I assume this also applies to handling of the fields?

I would assume so too. Let me ask around and confirm that.

Romain Lejeune

I think I am beginning to understand that this is not a good idea, because this method - in the cloud context - might not have access to the "start" field. Is that correct? Why does it still work in my case (is it because everything is local at the moment?)?

Yes, it'll work only if your "start" field was downloaded in your current transaction. Try to return self.n_clicks, and it won't work

Georg Kandler

Understood! Thanks for the helpful responses @Romain Lejeune