Attributes are the data elements, such as numbers, strings, or date values, that describe the state and contents of a BPM Object.
If an attribute has no read access, this means that its value is not accessible. On the contrary, if an attribute has no write access, its value cannot be changed.
All real attributes have both read and write access set by default. When an attribute is added to a BPM Object, it is created as a real attribute by default. When access methods are added to real type attributes, they override this default. When access methods are removed, they reset to the default. These changes never modify the read/write access of the attribute.
An attribute can be redefined as real or virtual by selecting or deselecting the Virtual check box available for the attribute in the BPM Object editor panel.
You must define at least one access method for a virtual attribute. If no access method is defined, the BPM Object compilation fails.
Read access has a return type identical to the attribute's return type. Write access receives an argument called value, which is of the same type and has no return type.
You must use a real attribute when you need to store a data element. You should use virtual attributes to expose values which can be calculated from existing real attributes. It may not always be obvious which values should be calculated and which should be directly stored. In the temperature example above we could have stored the Fahrenheit temperature while calculating the Celsius temperature
As a general rule, you should store what you consider to be the most natural value or the value you expect to use the most. The main thing is to avoid storing redundant information, since you risk ending up with divergent values for the same thing. Continuing with our example, if the object stores the temperature in Fahrenheit and also in Celsius, it will be possible to change only one of the values. The BPM Object would then contain two divergent values.