In Hyperledger Fabric, one asset has multiple transactions. These transactions update the state of the asset and maintain a trace as well.
Currently, if I want to have different transaction types for one asset, then I've written different functions in the chaincode which correspond to transaction types.
For example: If my assets are Cars, then each asset can have transactions of types sale, purchase, service, repair, etc. For each of these purchase, repair, service, etc., I've written a function in chaincode which gets invoked based on the type of transaction that is sent as input (type of transaction is sent as an argument in peer chaincode invoke command).
Do you think this is a good approach? What do you follow? What is recommended to achieve different transaction types? Also, how can I enforce different endorsement policies for different transaction types?
Note: I'm aware of the asset based (or key based) endorsement policies (Fabric v1.4) that can be written in chaincode. But this does not allow me to configure endorsement policies based on transaction types.
The pattern you are using is fairly typical ... chaincode is after all really just a state machine. It's fairly common to have different chaincode representing different types of assets or asset classes. You'll typically have multiple functions which manage the lifecycle of the asset (which it seems you do). The typical pattern is that the first argument when invoking chaincode represents the function you wish to invoke but up to you if you want to modify that pattern.
In terms of having different endorsement policies for different actions taken on the same state, this is not supported as it's typically not needed. You need to take care not to confuse endorsement policies (agreement on the output of an invocation) with an agreement protocol (e.g. I agree to sell you my car). That type of logic is typically handled within the chaincode function(s) (for example you'd check that the creator of the invoke is actually the owner of the car).
Hope this helps.
P.S. If you did want to have different endorsement policies for different transaction types, you could probably use state-based endorsement ... the policies are set via chaincode anyway ... so you could attempt to set the endorsement policy for each state based on the transaction type.