ITS sólo para Super Admin
Ver nota 939412.
Los permisos deben aplicarse a toda la ruta descrita.
ASCII Codes
Cuando hacemos un desarrollo Java con JSP, nos encontramos con el problema de que los caracteres tildados no se muestran de forma normal. Para solucionar esto, en mi “resource boundle” yo utilizo los siguientes códigos:
a -> “&#+225;” – “\u+00E1″
e -> “&#+233;” – “\u+00E9″
i -> “&#+237;” – “\u+00ED”
o -> “&#+243;” – “\u+00F3″
u -> “&#+250;” – “\u+00FA”
n -> “&#+241;” – “\u+00A4″
N -> “&#+209;” – “\u+00A5″
(Eliminando los “+”)
Se pueden usar unos y otros indistintamente.
Para más información:
http://www.lookuptables.com/
http://ascii.cl/es/codigos-html.htm/
Notas
Los recientes cambios legales que se han producido, por ejemplo en el IRPF nos han obligado a instalar un buen número de Notas en los sistemas de nuestros clientes. El procedimiento es el siguiente.
1) Comprobamos el nivel de parche de nuestro sistema en la Nota 115907. Para ello usaremos la información que encontraremos en el menú “Sistema -> Status” de nuestro sistema R/3. La versión del componente que debemos consultar es la de “SAP_HR”.
2) Comprobamos si hay nuevas Notas que instalar a fecha de hoy en la “Nota de Notas”: 167718. Estaremos atentos a que el nivel de parche de dichas notas sea superior al nivel de parche actual de nuestro sistema (En caso de ser menor o igual, no será necesario implementar la nota).
3) Una vez que tenemos la lista de notas a instalar, comprobaremos las características y pre-requisitos de cada una de ellas y procederemos consecutivamente de forma recursiva con cada uno de los pre-requisitos. De esta manera habremos creado un árbol de notas que deberemos recorrer desde las hojas hasta las raices. Deberemos tener en cuenta igualmente que los pre-requisitos son Notas normales que se rigen por las mismas reglas en cuanto a nivel de parche, pre-requisitos y particularidades…
4) Para implementarlas iremos a la transacción “SNOTE” y descargaremos la nota que queramos implementar y una vez descargada mediante el botón adecuado, la ejecutaremos seleccionándola en la rama “Nuevo” del árbol de la pantalla principal.
Una vez hecho esto con cada nota presente en nuestro árbol, habremos terminado de implementar las notas. Hay ciertos detalles que hay que tener en cuenta:
A) Algunas notas requieren actuaciones manuales tanto en su pre-instalación como en la post-instalación. Debemos estar muy atentos para cumplir estos requerimientos. (Ejemplo: 1256665).
B) Algunas notas requieren la actuación del equipo de Sistemas instalando ficheros .CAR. Ciertas notas sólo requieren este paso y la ejecución mediante “SNOTE” será innecesaria (Ej: 1292658); otras necesitan ambos pasos (Ej: 1171610).
Transporte del Portal
1) Transport Package.
Con un paquete de transporte, transportaremos el grueso del portal. En “System Administration” -> “Transport” -> “Transport Packages” -> “Export”, podemos crear un paquete de transporte en la carpeta que consideremos del árbol del portal. Una vez creado, añadiremos todos los elementos que sean necesarios (iViews, páginas, worksets, roles, paquetes de traducción, reglas y desktops… En general todo elemento que sea visible en la vista). Una vez hecho esto, nuestro operador de sistemas estará encantado de transportarlo.
2) Guided Procedures.
Seguro que hay una manera algo más elegante a la hora de transportar procedimientos guiados que el que voy a contar. Seguramente se pueda hacer una gestión de “Endpoint alias” más automática… Pero por falta de tiempo no se llegó a experimentar más. Cuando lo haga actualizaré esta entrada, de momento un método probado es este.
En el sistema de origen, configuramos un “Endpoint alias” entrando en “Guided Procedures” -> “Administration” -> “SAP System” -> “Configure End Points”. Aquí crearemos uno nuevo en caso de no existir ninguno. Introduciremos los datos del propio sistema.
Una vez configurado el Endpoint, nos dirigimos a “Transport” -> “Create Transport Request”. Le damos un nombre y comenzamos a añadir los procesos que queramos transportar; todos sus elementos. Deberemos hacerlo carpeta por carpeta. Una vez añadidos todos los elementos, terminamos la exportación.
Ahora en el sistema de destino, creamos un Endpoint con los datos del sistema de origen. Ahora en “Transport” hacemos la importación del paquete que antes exportamos, que estará visible en la lista y completamos la importación.
Ahora debemos modificar los datos del Endpoint y ponerle los datos de la máquina en la que nos encontramos. De otra manera se producirá un extraño efecto (Parece un error, pero dudo que lo sea) por el cual el GP trata de ejecutarse en la máquina de origen. Una buena gestión de Endpoints seguramente nos permita hacer esto sin estar editando los datos de nada… Pero lo dejo para una futura actualización.
3) KM Content
En “Content Admnistration” -> “KM Content” -> “Export” -> “Export Templates” creamos un paquete de transporte en el que introduciremos el contenido deseado.
Una vez creado y exportado tendremos el paquete disponible en “Archived Exports” para descargarlo a nuestro ordenador. Ahora en el sistema de destino, podemos hacer una importación del mismo haciéndo un upload del paquete. Ahora estará disponible en “Pending Imports”, donde podremos importarlo con la opción que más nos convenga (Si el paquete contiene todo lo que queremos en nuestro KM, recomiendo la primera opción “Delete conflicting data first”.
Java Stack
Cuando se produce un error en el portal, obtenemos una pantalla de aviso que es muchas cosas, menos tranquilizadora. Este efecto aplicado sobre los usuarios, puede dejarlos en shock y más si estás en una demo o algo así y el que paga ve semejante alarma de peligro nuclear mundial.
Sugiero los siguientes enlaces:
https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2629
Que nos sugiere cambiar la propiedad “DetailedErrorResponse” en la configtool del portal.
https://www.sdn.sap.com/irj/sdn/thread?forumID=41&threadID=1091579
Consiste en añadir bloques como el siguiente:
<error-page>
<error-code>500</error-code>
<location>/Error_Pages/500.jsp</location>
</error-page>
Al fichero web.xml del portal…
SAP JAR Finder
http://sapjarfinder.com/
http://sourceforge.net/projects/classlocator
Oro molido…
Canelita en rama…
KMList.par
Las especificaciones de mi cliente para este desarrollo son muy concretas y, para mi gusto, obtenemos un programa bastante feo y cuya salida por pantalla deja mucho que desear… Pero órdenes son órdenes.
Si eres muy novato, a lo mejor algún trocito de código te puede interesar y si eres observador aprenderás alguna cosita como la necesidad de un “contexto” y lo inservible de las variables globales en estas aplicaciones… Sin embargo tampoco es el código más limpio del mundo…
… Muy a mi pesar… Aquí está este código.
KMTree.par
La librería que el otro día construimos se queda absolutamente corta… La funcionalidad que ofrece es mínima y no me pareció suficiente como para construir el explorador que me han encargado desarrollar. Por ello, me volví a sumergir en el SDN y encontré un desarrollo que genera un árbol de exploración del KM: Justo lo que buscaba.
Aquí te proporciono un enlace a la página original, el .PAR compilado, las librerías necesarias para hacerlo y una lista de las mismas. En breve se actualizará este post con mi versión final que implementará las diferencias exigidas por mi cliente en particular.
La lista de includes es:
- bc.rf.framework_api.jar
- bc.util.public_api.jar
- com.sap.portal.htmlb_api.jar
- com.sap.security.api.ep5.jar
- htmlb.jar
KMTree.par (Recuerda sustituir la extensión JPG por RAR)
KMLibrary.jar
Estoy inmerso en el desarrollo de una aplicación que básicamente es un explorador de ficheros para el portal. En un principio se barajó el poner dichos ficheros en un servidor web a pelo, pero pronto aprendí que por motivos de seguridad, Apache y en general los servidores web, por motivos de seguridad, no atienden peticiones de Java, por lo que mi componente Java no podía explorar el directorio de dicha forma. El siguiente paso fue estudiar la posibilidad de FTP; este caso es perfectamente viable, siempre que tu cliente (Me refiero al que paga los garbanzos) no sea el mío. En ese caso, puedes usar la librería de Enterprise Distributed Technologies para realizar tus desarrollos.
El caso es que mi cliente no acepta la “inseguridad” de un FTP, así que lo siguiente que se planteó fue usar el KM directamente… Pero no les gusta la presentación que éste hace de la lista de ficheros, por lo que me veo en la necesidad de desarrollar un componente Java que explore el KM y lo presente a gusto del mecenas de turno. Para ello, encontré en el SDN (Tienes todos los enlaces que puedas estar deseando al final del post) el código de una librería para este propósito: El manejo del KM.
Me costó bastante encontrar los .JAR necesarios para cumplir los includes. A continuación te paso una lista de los mismos. Así mismo, te pongo un enlace a un fichero llamado KMLibraryrar.jpg al que deberás quitar la extensión JPG y sustituirla por RAR. En el paquete resultante tienes la librería compilada y los .JAR necesarios para su compilación/recompilación. La lista es la siguiente:
_webdynpro_progmodel.jar
bc.rf.framework_api.jar
bc.util.public_api.jar
com.sap.security.api.ep5.jar (Con Deprecated Warnings)
com.sap.security.core.ep5.jar (Con Deprecated Warnings)
webdynpro_services.jar
Las librerías con “Deprecated Warnings”, posiblemente tendrán alternativas más adecuadas que eliminen estos warnings… Este post será editado en caso de encontrar tales librerías. Si alguno de vosotros encuentra dichas alternativas, por favor, que me lo haga saber.
———
KMLibrary (Source / KMLibraryrar.jpg)
Otros enlaces de interés y ejemplos:
Enterprise Distributed Technologies (FTP Library / API)
http://www.jscape.com/articles/simple_ftp_using_java.html
http://forums.sun.com/thread.jspa?messageID=4332595
http://www.jajakarta.org/…/net/FTP.FTPDirectoryScanner.html
http://www.example-code.com/java/ftp_listDirectory.asp
http://www.javapractices.com/topic/TopicAction.do?Id=68
http://www.anddev.org/generalized_file_manager_2_-_gfm20-t397.html
