Los pedidos y los clientes de Shopware llegan a PostgresQL en el formato que se haya definido, por lo que lo que llega allí está diseñado para la función para la que se creó esta tienda en particular.
Una base de datos no tiene opinión sobre tu negocio. Acepta lo que se le proporciona, en el formato que se le ha definido, y procesará un pedido mal estructurado con la misma facilidad que uno bien estructurado. Por lo tanto, la primera pregunta es para qué sirve realmente la tienda, ya que generar informes y alimentar otra aplicación requiere cosas diferentes del mismo pedido de Shopware. Si no se responde, alguien escribe todo en una estructura general y se pierde su significado. Conectar Shopware y PostgreSQL comienza por definir ese formato, que es el único contrato entre ambos.

PostgresQL aparece mencionado en la documentación de soporte de bases de datos publicada por Alumio, por lo que los datos de Shopware se escriben directamente en la estructura que usted definió, en lugar de hacerlo a través de un cargador que alguien mantenga.
Cada pedido llega asociado a lo que lo identifica, por lo que una segunda carga actualiza lo que ya existe en lugar de agregar una copia casi idéntica que nadie nota hasta que el recuento parece incorrecto.
Las marcas de tiempo de carga viajan con los datos, por lo que cualquiera que los lea puede saber cuán reciente es una cifra en lugar de asumir que debe haber sido escrita en algún momento de esta mañana.
Dado que Shopware se lee según un cronograma y se prepara para su uso, la tienda no se consulta nuevamente con cada proceso que solicita los mismos pedidos, lo que reduce la carga de informes en la interfaz de la tienda.
Alumio escribe los pedidos de Shopware y sus líneas en PostgresQL con el formato que especifiques y en función de lo que uses para identificarlos, de modo que la tienda recibe lo que fue diseñada para recibir, en lugar de lo que la tienda devolvió por casualidad.
Una carga repetida coincide con lo que ya existe en lugar de insertarlo de nuevo, por lo que un almacén utilizado para informes no acumula lentamente pedidos duplicados que inflarían silenciosamente cualquier cifra que se extraiga posteriormente.
Cuando la tienda alimenta otra aplicación en lugar de un informe, solo se escribe en ella lo que esa aplicación necesita, por lo que sigue siendo algo en lo que un desarrollador puede confiar en lugar de una copia de todo lo que Shopware almacena.
Alumio se sitúa entre los canales de venta y los sistemas de cumplimiento como una columna vertebral de integración gobernada. Los pedidos se enrutan, transforman y validan, mientras que las actualizaciones de estado regresan a cada canal.
Autentique sus sistemas utilizando los conectores preconfigurados de Alumio. Elija entre más de 200 paquetes de conectores en el marketplace, además de integraciones personalizadas ilimitadas.
Defina cómo se asignan los campos de datos entre sistemas en una interfaz visual. Ajuste formatos, enriquezca registros y aplique lógica de negocio, sin necesidad de código personalizado.
Configure los flujos para que se ejecuten en tiempo real según eventos, según un horario o ambos. Reduzca la entrada manual de datos y deje que Alumio gestione el movimiento y la transformación entre sistemas.
Una vez que su primera integración esté activa, añadir su ERP, PIM, WMS o CRM se conecta al mismo centro. Los flujos existentes siguen funcionando. Sin necesidad de reconstruir desde cero.
Es importante decidir para qué se utilizará la tienda después de esto, antes de conectar cualquier otra cosa, ya que esto cambia la respuesta. Cuando PostgreSQL funciona como archivo en lugar de como fuente de datos, lo habitual es añadir un servicio de retención y archivo, puesto que conservar indefinidamente cada pedido de Shopware se convierte en un coste y una responsabilidad, en lugar de una ventaja. Alumio gestiona ambas conexiones, por lo que decidir qué se conserva y qué se transfiere es una sola decisión.
Lo primero es dónde se almacena y qué lo identifica; todo lo demás son detalles. Alumio lee los pedidos y clientes de Shopware que usted designe según la programación que haya establecido y los escribe en PostgreSQL con el formato que haya definido, haciendo coincidir los datos según sus identificaciones para que una carga repetida actualice en lugar de insertar. Solo se procesan los cambios relevantes, lo que evita que tanto la tienda como el sitio web realicen el trabajo dos veces.
No, y la forma es el contrato, no el código. Qué detalle de Shopware se ubica en qué parte de PostgreSQL, y qué lo identifica una vez allí, se define en la interfaz de Alumio, que también es donde se documenta por el mero hecho de existir. Dado que un diseño interno adopta las convenciones que su autor prefirió, el Code Transformer permanece disponible para cualquier elemento que no acepte un valor tal como está.
Por lo general, tratarlo como una sola cosa es un error. Un almacén PostgreSQL que recibe datos de Shopware es un destino para la escritura y una fuente para lo que lo lea después, por lo que la estructura que necesita depende completamente de la segunda mitad, y nadie puede mapear la primera mitad correctamente sin conocerla. Responder a la pregunta de qué lee esto, antes de decidir qué se almacena, es lo que impide una estructura amplia en la que nadie confía.
Una escritura exitosa en la ubicación incorrecta es un fallo que una base de datos nunca registrará, ya que no tiene motivos para hacerlo. Alumio detecta las escrituras rechazadas en el momento en que ocurren y registra dónde se insertó cada carga de Shopware en PostgreSQL y qué información contenía. Emite alertas inmediatamente cuando se rechaza una escritura, indica el motivo, reintenta la operación donde esté configurado y mantiene la carga en la lista hasta que se resuelve, de modo que no se inserta nada dos veces ni se pierde información entre ambas operaciones.
Habla con un especialista en integración de Alumio. Diseñaremos la arquitectura adecuada para tus sistemas, a la escala correcta, para que tus operaciones sigan siendo fiables ante cualquier cambio.