anchor.diff:  
   Antes de analizar el código del método será bueno ver una introducción exprés a la persistencia en JPA. 
   
  -En JPA el objeto central es el EntityManager. A través de los métodos de este objeto llevaremos a cabo las operaciones de persistencia que necesitemos. Los datos asociados a estas operaciones de persistencia serán jerarquías de las entidades persistentes, Drone, Trabajo y PuntoRuta, y deberemos gestionarlos dentro de una zona de memoria llamada contexto de persistencia. El contexto de persistencia no debe confundirse con la unidad de persistencia, cuya configuración se encuentra en el fichero persistence.xml, y que define un conjunto de entidades persistentes y su almacen de datos. En nuestra aplicación la unidad de persistencia será creada automáticamente y no tenemos que preocuparnos por esto.
  -
  -Las operaciones de persistencia que más usaremos serán: persist, find, merge y remove, que implementan, a grandes rasgos, las operaciones de alta, consulta,  modificación y baja, respectivamenete, conocidas por sus iniciales en inglés CRUD (Create, Read o Retrieve, Update y Delete). Por otra parte una entidad persistente, como por ejemplo Drone puede existir sólo en cuatro estados: new, managed, detached y removed.
  -
  -Para persistir información tengo que crear la jerarquía de objetos que queremos dar de alta, dar valor a los atributos y establecer las relaciones entre ellos. Cuando un objeto persistente es creado su estado es new. En este estado el bean aún no está dentro del contexto de persistencia pero al contrario que un objeto común tiene la potencionalidad de entrar en el contexto y en último término persistirse en la base de datos.
  -
  -El objeto EntityManager es usado desde la capa de negocio, donde se sitúa nuestro bean para la carga inicial de datos CargaInicialDatos y el bean que veremos en el próximo post para la implementación del caso de uso de nuestra aplicación. Como ya sabemos nuestra capa de negocio usa la tecnología EJB. En un bean EJB puedo inyectar directamente un objeto EntityManager que me proporcione acceso a un contexto de persistencia gestionado por el contenedor y tengo además  disponible la tecnología JTA, que proporciona una gestion de las transacciones automática, de modo que dentro de una transacción accederé por inyección siempre al mismo EntityManager, y éste será destruido cuando la transacción finalice. Es decir que usando EJB y JTA, como es el caso de nuestra aplicación, me puedo centrar totalmente en las operaciones de negocio y olvidarme de la gestión de los aspectos técnicos de la persistencia.
  -
  -Después de esta breve introducción teórica examinemos el código del método para afianzar algunos conceptos. El propósito de una carga inicial de datos es llevar a la base de datos la información del negocio existente antes de la puesta en producción de la aplicación. Para simplificar sólo daremos de alta un drone y un trabajo, con varios puntos de ruta, y estableceremos que el trabajo es realizado por ese drone. Si observáis el código del metodo podéis ver que sólo se manejan objetos de la capa de datos, quedando los detalles de la base de datos ocultos por la tecnología JPA. Veamos un poco más en detalle el código desde el principio. Es conveniente que tengais delante el diagrama de diseño que vimos en el post anterior para entender más facilmente el código:
  +En JPA el objeto central es el EntityManager. A través de los métodos de este objeto llevaremos a cabo las operaciones de persistencia que necesitemos. Los datos asociados a estas operaciones de persistencia serán jerarquías de las entidades persistentes, Drone, Trabajo y PuntoRuta, y deberemos gestionarlos dentro de una zona de memoria llamada contexto de persistencia. El contexto de persistencia no debe confundirse con la unidad de persistencia, cuya configuración se encuentra en el fichero persistence.xml, y que define un conjunto de entidades persistentes y su almacén de datos. En nuestra aplicación la unidad de persistencia será creada automáticamente y no tenemos que preocuparnos por esto.
  +
  +Las operaciones de persistencia que más usaremos serán: persist, find, merge y remove, que implementan, a grandes rasgos, las operaciones de alta, consulta,  modificación y baja, respectivamente, conocidas por sus iniciales en inglés CRUD (Create, Read o Retrieve, Update y Delete). Por otra parte una entidad persistente, como por ejemplo Drone puede existir sólo en cuatro estados: new, managed, detached y removed.
  +
  +Para persistir información tengo que crear la jerarquía de objetos que queremos dar de alta, dar valor a los atributos y establecer las relaciones entre ellos. Cuando un objeto persistente es creado su estado es new. En este estado el bean aún no está dentro del contexto de persistencia pero al contrario que un objeto común tiene la potencialidad de entrar en el contexto y en último término persistirse en la base de datos.
  +
  +El objeto EntityManager es usado desde la capa de negocio, donde se sitúa nuestro bean para la carga inicial de datos CargaInicialDatos y el bean que veremos en el próximo post para la implementación del caso de uso de nuestra aplicación. Como ya sabemos nuestra capa de negocio usa la tecnología EJB. En un bean EJB puedo inyectar directamente un objeto EntityManager que me proporcione acceso a un contexto de persistencia gestionado por el contenedor y tengo además  disponible la tecnología JTA, que proporciona una gestión de las transacciones automática, de modo que dentro de una transacción accederé por inyección siempre al mismo EntityManager, y éste será destruido cuando la transacción finalice. Es decir que usando EJB y JTA, como es el caso de nuestra aplicación, me puedo centrar totalmente en las operaciones de negocio y olvidarme de la gestión de los aspectos técnicos de la persistencia.
  +
  +Después de esta breve introducción examinemos el código del método para afianzar algunos conceptos. El propósito de una carga inicial de datos es llevar a la base de datos la información del negocio existente antes de la puesta en producción de la aplicación. Para simplificar sólo daremos de alta un drone y un trabajo, con varios puntos de ruta, y estableceremos que el trabajo es realizado por ese drone. Si observáis el código del método podéis ver que sólo se manejan objetos de la capa de datos, quedando los detalles de la base de datos ocultos por la tecnología JPA. Veamos un poco más en detalle el código desde el principio. Es conveniente que tengáis delante el diagrama de diseño que vimos en el post anterior para entender más fácilmente el código:
   
   * En primer lugar se crean y setean los beans PuntoRuta de la ruta para el trabajo. Se define una ruta triangular cerrada siendo el punto inicial y final por tanto el mismo. Podéis verla en la siguiente figura:
   
   image::https://raw.githubusercontent.com/lametaweb/lametaweb.github.io/master/images/003/post003-fig063.png[]
   
  -* A continuación se crea el objeto Trabajo y se inicializan sus atributos. Para el intervalo de comienzo y finalización del trabajo se calcula una hora hacia atrás y una hacia delante respecto del momento en que desplegamos la aplicación. Esto lo hago simplemente para que podamos probar la aplicación facilmente cuando la tengamos desplegada, de tal manera que para obtener el listado de drones realizando trabajos (sólo aparecerá el de la carga inicial) nos bastará con rellenar los campos de fecha y hora con la fecha y hora actuales.
  -
  -* Los objetos PuntoRuta son añadidos a la colección que implementa la relación uno a mucho entre Trabajo y PuntoRuta.
  +* A continuación se crea el objeto Trabajo y se inicializan sus atributos. Para el intervalo de comienzo y finalización del trabajo se calcula una hora hacia atrás y una hacia delante respecto del momento en que desplegamos la aplicación. Esto lo hago simplemente para que podamos probar la aplicación fácilmente cuando la tengamos desplegada, de tal manera que para obtener el listado de drones realizando trabajos (sólo aparecerá el de la carga inicial) nos bastará con rellenar los campos de fecha y hora con la fecha y hora actuales.
  +
  +* Los objetos PuntoRuta son añadidos a la colección que implementa la relación uno a muchos entre Trabajo y PuntoRuta.
   
   * Creamos el objeto Drone y seteamos los atributos. En este punto el contexto de persistencia está aún vacío.
   
  -* Queremos guardar dos objetos independientes, Trabajo y Drone, entre los que existe una asocicación bidireccional y uno de ellos, Trabajo, se relaciona además con N objetos dependientes PuntoRuta. Entendemos independientes en el sentido de que no hay una relación todo/parte y por tanto su persistencia se debe gestionar de forma independiente. Tendremos que persistir por separado los dos objetos, además de la relación. Para los beans PuntoRuta no ocurre igual como veremos en un momento. 
  -
  -* En una relación bidireccional existe lo que se entiende por lado dueño de la relación, que es aquel en el que se expresa la relación. En este caso el lado dueño de la relación entre Drone y Trabajo está en la entidad Trabajo ya que a través de la anotación @JoinColumn se expresa alli la relación. Como lo que queremos es persistir la relación bastará con dar valor al lado dueño.
  +* Queremos guardar dos objetos independientes, Trabajo y Drone, entre los que existe una asociación bidireccional y uno de ellos, Trabajo, se relaciona además con N objetos dependientes PuntoRuta. Entendemos independientes en el sentido de que no hay una relación todo/parte y por tanto su persistencia se debe gestionar de forma independiente. Tendremos que persistir por separado los dos objetos, además de la relación. Para los beans PuntoRuta no ocurre igual como veremos en un momento. 
  +
  +* En una relación bidireccional existe lo que se entiende por lado dueño de la relación, que es aquel en el que se expresa la relación. En este caso el lado dueño de la relación entre Drone y Trabajo está en la entidad Trabajo ya que a través de la anotación @JoinColumn se expresa allí la relación. Como lo que queremos es persistir la relación bastará con dar valor al lado dueño.
   
   * La persistencia la hacemos de la siguiente manera: Persistimos primero por ejemplo el objeto Drone, usando el método _persist_ del entity manager. Esto provoca un cambio de estado en el objeto Drone desde new a managed. El objeto está ahora dentro del contexto de persistencia. No está aún en la base de datos. Y a continuación persistimos el objeto Trabajo. Y finalmente damos valor al lado dueño de la relación. El orden de las operaciones os puede extrañar pero he querido hacerlo así para aclarar los conceptos. Al persistir una entidad ésta pasa a estado managed en el contexto como ya hemos visto, pues bien, todos las asignaciones sobre los atributos de una entidad managed serán persistidas, cuando la transacción se complete. La transacción se completa cuando el método termina de ejecutarse. En este punto el proveedor de persistencia sincroniza el contexto de  persistencia con la base de datos, comprobará que en el contexto existen varias entidades managed que no existen en la base de datos y procederá a darlas de alta. Para aclarar aún más esta cuestión os diré que en el método de carga los métodos persist de drone y trabajo podríamos haberlos colocado justo debajo de línea que crea cada bean.
   
  
positive.code:     private EntityManager em;
  ----
      
  * Y finalmente añadimos el método para la carga inicial de datos anotado con _@PostConstruct_, quedándo el código de la clase así:
  
  [source,java]
  ----
  
negative.code: 
  Un origen de datos o datasource es un recurso de servidor que permite a una aplicación comunicarse con un gestor de base de datos, a través del proveedor de persistencia, para realizar operaciones de consulta y modificación sobre un   esquema de datos. El origen de datos necesita sin embargo un elemento adicional para realizar su función, el driver JDBC, que consiste en un conjunto de librerías que traducen los comandos del proveedor de datos en comandos específicos de la base de datos utilizada: Oracle, PostgreSQL, MySQL, etc. 
  
  La instalación del datasource puede hacerse de distintas maneras. En nuestro caso la incluiremos dentro del ciclo de construcción del proyecto, en el archivo pom.xml, para que de este modo tengamos toda la información necesaria para el despliegue en un mismo sitio. También veremos sin embargo una manera de instalar el datasource en el servidor de forma manual, no automatizada, ya que es como comúnmente se hace en proyecto reales.
  
  Bien, empezamos. Abrimos Eclipse y a continuación el fichero pom.xml del proyecto. Añadimos la dependencia correspondiente al driver JDBC de Derby del que tirará el datasource con un copia pega del siguiente fragmento de XML dentro del elemento _<dependencies>_:
  
  