.Net Processes - Map Step Feature

[crickman]

Motivation and Context

Fixes: #9193

Description

Map each value from a set to a map-operation and present the results as a set for potential reduction.

Includes:

• ProcessMapBuilder (Core)
• KernelProcessMap / KernelProcessMapState (Abstractions)
• LocalMap (LocalRuntime)
• MapActor (DaprRuntime)
• Serialization
• Unit Tests (exhaustive)
• Integration Tests
• Sample

Features:

• Executes map operations in parallel
• Handles when output type has been transformed from input type
• Accepts either step or subprocess for map operation
• Proxies events for edges defined directly on the map-step
• Allows additional (non proxied) edges for the map-operation
• Participates in state serialization

Follow-up:

• Documentation - .Net Processes - Document Map Step #9616

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[esttenorio]

[brainstorming hypothetical scenario]
wondering if these 2[line 40-41] should be a single function? since compute is not actually used by the root process directly having it instantiated on the level computeStep could in theory also be used as a regular step:

graph TD
root["root process"]-->map-->compute1["compute"]
root-->compute2["compute"]

Loading

[crickman]

Good question. Ben and I were discussing this also. There is a case where an edge may be defined outside of the map-operation: https://github.com/microsoft/semantic-kernel/blob/processes-map-step/dotnet/src/Experimental/Process.UnitTests/Runtime.Local/LocalMapTests.cs#L295

graph TD
root["root process"]--N-->map
subgraph map
compute1["compute"]
end
compute1["compute"]--1-->orthogonal
compute1["compute"]--N-->union
root--extra/noharm-->compute2["compute"]

Loading

The other factor to consider is when the map operation is a subprocess...such a pattern would also result in being explicitly handled by the caller (first create sub-process, then associate with map). The difference for step is that the builders only allow creating one from the process builder...which in turn always adds it to the step collection of the process.

I'm am certainly open to exploring any potential improvements, but it also feels like we need to be careful to consider the breadth of patterns that make sense and avoid disrupting others that are useful.

FYI - I'll planning on spending some time exploring alternative patterns here...just want to be careful.