Bump. Guess my question is either very daft or very good (since it has no comments yet).
Has nobody ever come across this requirement? Or maybe I'm overlooking something obvious which renders the requirement useless? Might even be, that my design-approach itself is bonkers.
O que quero alcançar
: Quero que a distribuição, ou seja, a visibilidade, das aplicações que usamos em nosso portal seja controlada de forma centralizada através de autorizações em funções do R/3. Portanto, pensei em utilizar apenas uma função de portal personalizada que contenha todo o conteúdo que os usuários poderiam ter (mas não necessariamente têm) para o nosso conteúdo remoto (ou seja, o que vem do FES em nosso Gateway). A vantagem que vejo pessoalmente ao fazer isso é que podemos ter uma função de portal e uma função do R/3 mapeada (como âncora) como conexão técnica. Portanto, ao adicionar conteúdo ao nosso ambiente, seria necessário apenas adicionar os catálogos remotos a esta única função de portal e atribuir funções do R/3 dedicadas que contenham a autoridade para esses catálogos (ou seja, se você não tiver autoridade do R/3, não poderá ver o conteúdo, mesmo que esteja tecnicamente disponível na função de portal) e, ao atribuir a função do R/3 respectiva, assumindo que grupos são utilizados, o usuário respectivo verá automaticamente o novo conteúdo (grupo com catálogos) em seu portal.
O que quero evitar
: Estou ciente de que o conteúdo remoto e o conteúdo de portal dedicado através de iViews/Pages podem ser usados simultaneamente, mas com meu conhecimento atual vejo os seguintes problemas: Se eu atribuir um iView a uma função de portal, o usuário final não terá automaticamente o mosaico em seu FLP, ou seja, ele terá que ir manualmente para o Explorer de aplicativos e adicioná-lo a um grupo. Outra observação estranha que fiz é que aparentemente isso pode ser feito independentemente das autorizações no backend, o que significa que pude adicionar um mosaico de um iView para o qual não tinha autorização no backend. Portanto, isso significa para mim que não posso simplesmente colocar todo o conteúdo do portal em uma função, porque os usuários verão coisas que não deveriam. Mais uma vez, isso significa que eu teria que construir funções de portal dedicadas e então mapeá-las e fundi-las com funções do R/3 dedicadas, além, provavelmente, de fazer fusões de funções de portal, etc. (como era no Framework da página inicial há 10 anos). Tudo isso parece muito complicado em contraste com o Launchpad WDA atual, onde posso controlar tudo de forma centralizada, independentemente da fonte.
Qualquer pensamento/comentário é muito apreciado. Muita boa karma virá para você.
