Use case for function CreateSessionInfoForAnotherApp

I just tested it. You can use it to access data from another application:

Dim oar As New OpenAppResult
Dim osi As SessionInfo = BRApi.Security.Authorization.CreateSessionInfoForAnotherApp(si, "OtherApp", oar)

If oar = OpenAppResult.Success Then
	Dim dciums As DataCellInfoUsingMemberScript = brapi.Finance.Data.GetDataCellUsingMemberScript(osi, "OtherAppsCube", "OtherAppsDatacellPov")
	brapi.ErrorLog.LogMessage(si, "Cell Amount" & dciums.DataCellEx.DataCell.CellAmount)
end if

As Christian mentioned, you can use this to execute a BRApi against other applications that exist within the same environment by retrieving another application's session info. A powerful use case I've seen is to create a UD8 dynamic calc that enables you to pull cube data from another app into a cube view so that you can report on and compare data in multiple OneStream apps that live in the same environment. Below is an example of a UD8 calc that can enable you to accomplish this.

'define the other application name you wish to connect to - this must be an app that lives within the same environment
'the user must also have access to the application to authenticate to it
Dim otherAppName As String = "SomeOtherApp"
'create the session info to the other app and store it globally in memory
Dim otherAppSeshInfo As SessionInfo = globals.GetObject("OtherAppSeshInfo")
If (otherAppSeshInfo Is Nothing) Then
	otherAppSeshInfo = BRApi.Security.Authorization.CreateSessionInfoForAnotherApp(si, otherAppName, OpenAppResult.Success)
	globals.SetObject("OtherAppSeshInfo", otherAppSeshInfo)
End If
'get the POV intersection from the CV and swap out the UD8 none member with the name of this UD8 reporting member
Dim povMemberScript As String = api.Data.CreateMemberScriptBuilder(True, True, True, True).GetMemberScript().Replace("U8#GetDataFromAnotherApp", "U8#None")
'return the POV cell amount from the other application
Return BRApi.Finance.Data.GetDataCellUsingMemberScript(otherAppSeshInfo, api.Pov.Cube.Name, povMemberScript).DataCellEx.DataCell.CellAmount

Regards,

Nick Kroppe

Cosimo

It can be used if, let's say, there is a history app and you need to pull People Planning data. I cannot think of a different scenario at the moment.

Source session info is the current app you are logged in to, and you are now generating destination session info using this command. Anything you need from the destination, use the destination session info.

Dim objOpenAppResult As New OpenAppResult()

Dim siDest As SessionInfo = BRApi.Security.Authorization.CreateSessionInfoForAnotherApp(si, "OneStream_GolfStream_v44",objOpenAppResult)
Dim objDBWheres As New List(Of DbWhere)
Dim objDBWhere As New DbWhere("RegisterID",DbOperator.IsEqualTo,"E000204")
objDBWheres.Add(objDBWhere)
Dim objScnWhere As New DbWhere("WFScenarioName",DbOperator.IsEqualTo,"BudgetV1")
objDBWheres.Add(objScnWhere)
						
Dim strFirstName As String = BRApi.Database.LookupRowFieldValue(siDest, "App", "XFW_PLP_Register", objDBWheres, "FirstName","")
BRApi.ErrorLog.LogMessage(si, strFirstName)
siDest.CloseApplication()

Thank you Christian/Nick/Celvin!  This also explains the need for providing sessionInfo as a parameter to lots of BRApi functions. It always felt redundant to provide si in functions but given that we can run functions across applications, it all makes sense. 

This is a great UD8 trick and will make data reconciliation between apps much easier.   I have a question about multiple applications.  I know typically people think of OneStream as having everything within one application seperated by cubes.  Working on an application where Planning activities are quite different than existing consolidation activities and I am a bit weary of trying to jam it all into the existing Consolidation application.  I am wondering if it would be easier to organize in a seperate application altogether so there would be a planning application and a consolidation application and the planning data would eventually be loaded into the Consolidation Application after it's approved.  There are a number of reasons that lead me to entertain this idea one of which is performance and that we may only ever want to 'Aggregate/C#Aggregated' the data in Planning and 'Consolidate/C#Local' the data in the Consolidation application and we don't want it to get confusing with what data to use for the users.  Other reasons relate to unrequired members and performance tuning that might not lend itself to combining apps and feels like I could be combining them for the sake of combining them.  Is two applications a 'sanctioned' idea in OneStream?  The OS Planning Book references the word 'Planning Application' from time to time and that suggests they could be referring to a seperate Planning application as opposed to just a seperate cube.  Thoughts?

Mike