Como crear un entorno de desarrollo desde una instalación en producción.

Filed under:3.0,4.0,AOS,SQL,desarrollo,oracle — posted by admin on July 8, 2008 @ 2:28 am

Ahora q esta muy de moda lo del cambio contable por la nueva ley vamos a hacer un entorno de desarrollo.

Nos encontramos en algunos casos que una cambio de Service pack o una actualización grave sobre producción representa una incompatibilidad entre el trabajo de los usuarios y las tareas de desarrollo, sin llegar a exagerar como las instalaciones que hacíamos cuando heramos esclavos de las consultoras y a la “grupy” financiera de turno se le ocurría de debíamos tener el entorno de producción, el de preproducción y el de desarrollo. No es mala idea tener un lugar en el que poder trabajar con libertad tanto para desarrollo como para pruebas funcionales.

Axapta básicamente esta compuesto por un código fuente que se almacena en unos directorios dentro de unos archivos específicos y una base de datos. Todo esto no funciona sin un programa que interprete estos archivos y los enlace con la base de datos.

De esta manera para hacer un entorno de desarrollo a partir de producción solo debemos mantener esta coherencia directorio base de datos.

Ejemplo practico.

Tenemos una instalación tipo, 3.0 spX con una base de datos SQL server X.

Nuestra instalación se encuentra situada en “C:\Navision\Axapta Application\Appl” dentro del directorio tenemos los directorios de las diferentes aplicaciones. Normalmente Standard y producción.

Copiando producción y renombrar el directorio como Test ya tendríamos la mitad de nuestro entorno de desarrollo.

Después solo hay que realizar una copia de seguridad de la base de datos completa y restaurarla con otro nombre.

El último paso seria configurar el cliente o el AOS para que accedan al nuevo entorno y sincronicen los posibles cambios.

Como ejecutar un archivo cmd o .bat desde un cliente sobre el servidor AOS

Filed under:3.0,4.0,AOS,dynamics,x++ — posted by admin on March 27, 2008 @ 4:27 am

Para poder crear un archivo tipo bat o cmd con definirlo de esta manera “file = new asciiio(‘c:\\filex.bat’,'w’);” ya tenemos un fichero llamado filex.bat en c:\ . Ahora bien en nuestro c: o en el del sevidor???? Pues eso solo lo sabremos si el metdodo q hemos ejecutado se lanza del lado del cliente o del lado del servidor, y para salir de dudas mejor definir una metodo static y ponerle server para que de fijo se lance en el servidor donde se este ejecutando nuestro AOS (AX32serv.exe).

static server void Start()
{
asciiio file;
str txt;
;
winapi::deleteFile(‘C:\\file2.txt’);

file = new asciiio(‘c:\\filex.bat’,'w’);

if (file)
{
txt = (strfmt(‘net start “Axapta batch 1″ ‘));
file.write(txt);

file = null;

winapi::shellExecute(‘c:\\filex.bat’);
winapi::deleteFile(‘C:\\filex.txt’);
}

}

ftx_tpv_shutdownrestartservices.xpo

dibujo111111.JPG

Como instalar un cluster de AOS en 3.0 y para que sirve.

Filed under:3.0,AOS,axapta,dynamics — posted by admin on March 6, 2008 @ 1:20 am

Buenas, pues todo el mundo sabe lo que es un cluster de maquinas no??,  el que no se pede pasar por la wiki y luego seguimos.

Total  Ax (axapta 3.0) permite instalar un balanceador de conexiones entre dos o mas AOS, para que sirve esto, pues más bien para no mucho, el concepto es que el dependiendo del número de usuario que se han conectado a un u otro AOS este cluster distribuye la conexión entrante para mantener un numero homogéneo de conexiones. 

Nada de  transacciones o de carga de procesos, simple y “molt macu” para vender un poco de tecno-logia al puro estilo de las modas de internet. Seguro que en un par de meses se les ocurre algo para dual core.. jajjajaa..

Para terminar un copy paste de como se instala y se configura.. Perdon por los derechos de autor.. jejjeje

Axapta Object Server cluster

The Axapta Object Server cluster environment is build to provide load balancing and fall back. An Axapta Object Server can be specified to belong to a specific cluster. If the same cluster name is given for a number of object servers they all belong to the same cluster. A user can be specified to connect to a given cluster.

Suppose a number of servers are set up in the same cluster – named AOSC. They should all use the same application and database, and in other aspects have the same settings. All clients connecting to the AOSC should be specified to search for servers belonging to this cluster, otherwise the load balancing mechanism will not work properly. A client starting up against an Axapta Object Server Cluster will start out by broadcasting an UDP package requesting Axapta Object Servers fulfilling names and IP server masks given in the client settings to respond. It is therefore vital that firewalls allows such packages to pass through. The client will receive answers from all Object Servers with information on object server name and the name of the instance plus the number of clients connected to that instance. The client disregard information from servers not belonging to the requested cluster. The client then chooses one of the instances with the lowest number of clients.

Since a client automatically can choose from all servers in a cluster one or more Object Servers can be down with out changing the connection procedures. However performance might suffer severely due to higher load on the fewer servers.

Setting up the server

On the server manager select the server of interest and click settings. In the advanced field write -cluster=<my cluster name>. The cluster name can be up to 10 characters long.

Setting up the client

In the configuration tool choose the configuration of interest. In the advanced field write -cluster=<my cluster name>. The client setting for connecting to an object server depends on two situations. The first situation being both client and Axapta Object Servers being in the same subnet. The second being client and Axapta Object Servers belong to different subnets.

Recall the settings in the configuration utility for connecting to an object server:

- Axapta Object Server Mask
- Axapta Object Server host names
- Axapta Object Server IP Address masks

When the client and Object Servers belong to the same subnet the above three masks can be left blank.

When the client and Object Servers belong to different subnets the IP Address masks should contain the mask for the subnet the Object Servers belong to. An example could be 192.88.253.255, where the last 255 specifies that the search is done among servers in the subnet 192.88.253.*.

Note – if client at any time receives only service response from Object Servers within the same cluster it will automatically choose the least loaded of these servers without having to specify the cluster name in the client configuration. This means that if your installation is one single Axapta cluster, there is no need to change the existing configuration with respect to cluster name. Ensure that all relevant Object Servers are located by client configurations network set up.



image: detail of installation by Bronwyn Lace