Nuevamente yo. Tengo una duda.
Tengo tres servidores PRO QUA DEV 100 y 110.
Yo trabajo en DEV hasta que decido transportar y mi programa, y ruego por que sea lo que visione 
El asunto es que en DEV no tengo datos de prueba para poder determinar correctamente si mi programa hace lo que quiero que haga. 
Quisiera que los datos de PRO estuvieran en DEV para probar con registros actuales o por lo menos del ultimo bimestre.
¿Como le hago?
saludos a todsssss.
@silver en la mayoria de los clientes esto no se hace, porque los recursos de los cuales dispone DEV son minimos, se supone que ese server es solo para desarrollos, maximo estaran entrando uno o dos usuarios a la vez, podrian ser 5 si es un equipo. Asi que dedicar recursos al DEV seria un gasto poco probable.
Mi recomendacion es que realices todas las pruebas que sean necesarias en QA y luego que sepas bien lo que vas a hacer, vas a de DEV y listo. Con el tiempo te acostumbraras a programar pensando en como seria el resultado si tuvieras DATOS xD.
mmm, es que si da weba subir versiones cada 15 min jaja, porque ni en QA tengo datos buenos.
pero bueno empezare a acostumbrarme. Porque toy sólito. no tengo ningún equipo de trabajo.
grax.
QA es tu hermano mas cercano. Entiendo todo lo que dices. Me paso a mi, pero ya ni mente le doy al pase de ordenes, lo hago como que asi es la vida, y asi es.
Dependerá también de tu cliente, y sus recursos.
Yo he trabajado en clientes donde dentro de DEV, tienen un pequeño repositorio de datos para lanzar pruebas. Es más, también se denomina SANDBOX.
Es como un pre-qas. Un intermediario entre DEV y QAS.
Pero eso como dije, dependerá de cuánta pasta tenga tu cliente y cuántos ambientes requiera su lógica de negocio.
Lo más común.
Es tres ambientes:
Saludos!!!
Mis tres servidores son iguales, solo PRD tiene mas disco. Es la única diferencia.
QAS tiene el BI, asi que pensé porque no en DEV. Pero como dice @smota, se me debe impregnar en el ADN lo de los transportes. nimodos. jeje.
Como indican anteriormente, debes enfocarte en homologar los ambientes PRD y QAS. El ambiente de desarrollo no deberias cargarlo de datos.
En mi caso estoy con una compañera programando. Y hemos aprendido de los diferentes modulos activos en nuestro sistema para realizar pruebas en desarrollo. Por ejemplo podemos hacer una entrada y salida de materiales, o el ciclo completo de compras, hasta llegar a la facturación para verificar el comportamiento de un reporte dado. De no ser posible en desarrollo, si pasamos a calidad y se realizan las pruebas respectivas.
Saludos.
Concuerdo con los comentarios que hacen, deberías trabajar en QAS para realizar las pruebas y realizar la configuración en DEV.
Entiendo lo que dices que es un poco tortuoso estar liberando transportes y pasándolos a calidad para ello puedes realizar un JOB que este pasando estos transportes en automático una vez que ya están liberados, con ello te quitas ese trabajito.
En DEV por ser generalmente un servidor con menos recursos no siempre es grande en capacidad, tengo entendido que cuando haces una copia de PRODUCTIVO a otro ambiente sea QAS o DEV, pasas todo, y no puedes decirle pásame solo 1 mes de PRODUCTIVO A QAS, tengo entendido eso.
Saludos.
Buenas @silver, me imagino que puedes pedir una copia de mandante a QAS, así tendrías datos buenos en dicho entorno y podrias hacer pruebas más fiables. De todas formas, está claro que aunque los datos pueden ser buenos, el desarrollo necesite ajustes y a veces transportar una versión por un if y ver que no fuciona y volver a transportar otra 12 minutos más tarde y así sucesivamente es para subirse por las paredes.
¿por que no cambias directamente el código en QAS y cuando estés seguro que funciona lo copias a DEV y lo transportas? ¿conoces la función TRINT_OBJECTS_CHECK_AND_INSERT? Es más o menos ese nombre, porque estoy en casa y no me acuerdo de memoria. Con esta función y un break-point concreto podrás cambiar tus reports y funciones, activarlas y probar en QAS aunque el mandante esté cerrado para modificaciones.
Suena bien, Desconozco muchas funciones que ayuden a programar mas rápido y eficiente, estoy iniciando con ABAP, seria genial si me pasas mas detalles de como usarla, porque es un hecho, en una semana que llevo con esto, ya quiero vacaciones, jaja, Termine ayer un reporte que… de ver el codigo nomas veo cosas feas, incluso me ayudaron aquí, con lo mas fácil porque ni eso podía jaja.
voy a abrir un tema, para ver si se puede enchular, porque funciona pero no estoy muy seguro de que sea la mejor forma de hacerlo.
Estimado @silver
Lo que se hace para tu requerimiento es como indica @SidV, un sandbox.
Un sandbox es otro mandante en donde mantienes la configuración + datos de prueba, esto se hace generalmente para encapsular desarrollos que puedan interferir potencialmente con objetos actuales de uso workbench, proyectos generalmente.
la utilidad de tener un sandbox de DEV es justamente para lo que necesitas, verificar la aplicación de un desarrollo y asegurar la consistencia antes del paso al ambiente QA.
Recordemos que las cambios workbench se visualizan en todos los mandantes de un ambiente, mientras que los cambios customizing son dependientes de mandante
Por que asegurar?, en DEV puedes generar cambios de customizing y copiar la OT mediante SCC1 al sandbox sin necesidad de liberarla.
Esto permite realizar pruebas unitarias y no dejar el QA con posibles errores o desarrollos incompletos que puedan afectar a los diferentes modulos de SAP o el sistema mismo. Acá dices, “si me queda malo QA no importa, hacemos una copia de PRD y listo”, bueno esto no es tan fácil en organizaciones grandes donde los datos de productivos son gigantes, generalmente va asociado a un costo y tiempo… tiempo en donde no contaras con el ambiente de QA.
como se pobla el sandbox? no con datos de producción sino mediante cargas masivas LSMW donde cargas generalmente datos maestros y tu generans los documentos necesarios para realizar tus pruebas. Con esto me refiero a poquísimos datos, solo los necesarios.
Espero esta información les sea útil.
Saludos.
Entiendo que vos necesitas es un SandBox en Desarrollo para poder probar los desarrollos antes de pasarlos a Calidad / Producción. Si bien queda a criterio de la gente de Seguridad, en la práctica (OJO, yo te comento los pasos. La responsabilidad es tuya. Documentación hay mucha para consultar) (la operación se denomina Client Copy) :
Previo backup completo del servidor de destino y disponer de espacio en el disco del S.O. y donde tengas alojadas las bases de datos.
Desde PRD: SCC8 Esportar Mandante. generalmente en este caso se usa el perfil SAP ALL para copiar datos, roles, usuarios pero nada fuera del mandante. Elegís el Sistema Destino (en este caso DES), probas la comunicación RFC y comenzás a hacer el “Transporte” para exportar. Tarda, podes monitorearlo con SCC3 opción Exports. Te genera un documento que indica los pasos a seguir y después arranca.
En DES: O haces un mandante nuevo con SCC4 o pisas el Sandbox existente. Ingresas al mandante destino (tiene que estar abierto para recibir transportes), usas la STMS // Detalles // Otras Ordenes // Buscar en grupos externos y te trae la orden de transporte que generaste en PRD con la Exportación. Tarda mucho (en algunos casos casi seis horas, paciencia)
Cuando terminó, la transportas y esperas nuevamente (mucho tiempo). Al finalizar solo queda verificar la exportación con SCC7.
Espero Silver que te sirva como una pequeña guía.
Saludos
Estimado @silver
Todo lo que necesitas es solicitar al basis de tu empresa que realice una copia de mandante desde PRD a QA o incluso al mismo Sandbox, si como dices los servidores son iguales no deberias tener mayores problemas, donde trabajo los hacemos cada tres meses aproximadamente por el mismo tema de poder contar con datos mas o menos actualizados para las pruebas y entrenamientos que se dan constantemente
Si necesitas ayuda para realizar la copia de mandante avisame aunque el basis debe estar capacitado para hacerlo
Saludos
Hola @silver , aún cuando la práctica correcta es tener 3 entornos, como dicen el resto de compañeros, hay muchos clientes que trabajan con DES y PRD directamente. Esta práctica dista mucho de la idealidad y no debería hacerse, sin embargo no es raro encontrarse con esta situación.
Si por un casual dedides como un cliente nuestro realizar una copia de PRD y utilizar el PRD antiguo como Calidad o DES, ten en cuenta que luego tendrás que reconfigurar todo el sistema de transporte, ya que el original no será el mismo.
Un saludo.
Este tema se cerró automáticamente 91 días después del último post. No se permiten nuevas respuestas.