Published July 8, 2008 | 
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.
Published June 2, 2008 | Para poder colocar las estadisticas de google o cualquier otro servidor de analisis, solo necesitamos localizar la pagina que siempre se ejecutara por defecto en nuestro AEportal. En este caso Standard Home page.
Introducimos el jscript que nos proporciona el servidor de analisis y actualizamos la version.
Published April 18, 2008 | Un documento de cuando AX era Daangard
When setting up an Oracle database to work with Axapta it is often (normally) configured as a dedicated database server for the following reasons:
· Until now this has been the default behavior of an Oracle database.
· Early versions of the multithreaded server was known to be unstable and with some annoying bugs.
The backside of configuring the database as a dedicated server is:
· Each new database connection creates a process / thread on the server.
· Each new database connection allocates more memory for PGA purposes than a similar multithreaded connection.
As you increase the number of concurrent users in an Axapta system you will also increase the administrative burden of the Oracle database server, because you will start new processes / threads on the database server for each new Axapta session. At one point this task of switching between processes / threads will be so overwhelming big part of the servers activity that it will “kill performance” on the server.
Large Oracle Axapta installation with several hundred concurrent Axapta session are therefore more or less forced to configure their database as a multi threaded server.
Axapta running in 2-tier mode has in average 3-4 database connection, which is why configuring your Oracle database as multithreaded will ease the database servers tasks of administer the processes / threads and decrease the consumption of memory. Even though Axapta in 2-tier mode is more expensive database connection wise compared to 3-tier mode you will still benefit from using multithreaded server when running Axapta in 3-tier mode.
This document describes in short how to your Oracle database as a multithreaded server.
1. Oracle init.ora parameters
If you want to understand the way a multithreaded server works compared to a dedicated server, then you can read about this in the following 2 Oracle manuals:
· Oracle Concepts
· Oracle Administrator guide
The following Oracle kernel parameters must or can be specified in order to make the Oracle database server run in multithreaded server mode. A detailed description of these parameters can be found in the “Oracle Reference” manual.
Parameters
mts_dispatchers: Controls the protocol and number of dispatcher processes started at instance start. In the most simple way you just specify the protocol and the number of dispatcher processes stated at instance start:
· mts_dispatcher=”(protocol=<protocol>)(dispatchers=<n>)”
<protocol> would typically be TCP and <n> is the number of dispatchers. You can specify multiple MTS_DISPATCHERS in the initialization file, but they must be adjacent to each other.
To specify that you want to start 5 dispatchers for the TCP/IP protocol at instance start you must specify as follows:
· mts_dispatcher=”(protocol=TCP)(dispatchers=5)”
mts_max_dispatchers: Specifies the maximum number of dispatcher processes allowed to be running simultaneously. Default: 5 or the number of dispatchers configured, whichever is greater. For most systems, a value of 200 – 250 connections per dispatcher provides good performance.
mts_servers : Specifies the number of server processes that you want to create when an instance is started up. If system load decreases, this minimum number of servers is maintained. Therefore, you should take care not to set mts_servers too high at system startup.
mts_max_servers: Specifies the maximum number of shared server processes allowed to be running simultaneously. If artificial deadlocks occur too frequently on your system, you should increase the value.
Default: Derived from mts_servers (either 20 or 2*mts_servers) .
Tests in out benchmark lap shows that in order to avoid artificial deadlocks in a 3-tier environment you should specify mts_max_servers as 1.2 * Number of active Axapta sessions. If you have 500 concurrent Axapta sessions, then you should specify mts_max_servers to be 600.
instance_name : Name of the instance. Default value is the instance’s SID. NB! Due to a bug in Oracle 8.1.7 you must specify this parameter in order to run multithreaded server.
2. Start of multithreaded database environment
After you has changed the Oracle initialization parameters in your init.ora file, then you must bounce the database (shutdown and start again). This you have to do to let the dispatcher processes be registered by the listener process and thereby start the database as multithreaded. When running a multithreaded database you must always start the listener processes before you start the database. If the database is started before the listener, then the database will start the dispatcher processes, but because the listener don’t know their existence the database will run as a dedicated server.
Check in your alert log for your database that the dispatchers has started. Just after the start banners of the database and non-default system parameters you should find 2 lines looking something like this:
starting up 5 shared server(s) …
starting up 2 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL=tcp))’…
To make sure that the listener has registered the dispatcher processes correctly start the listener control utility and list services supported by the listener (bold text indicates the commands you have to execute):
C:\>lsnrctl
LSNRCTL for 32-bit Windows: Version 8.1.7.0.0 – Production on 14-MAY-2001 12:37:27
(c) Copyright 1998 Oracle Corporation. All rights reserved.
Welcome to LSNRCTL, type “help” for information.
LSNRCTL> set password oracle
The command completed successfully
LSNRCTL> services
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=wk0-kma-dev-nt4)(PORT=1
21)))
Services Summary…
AXDB has 3 service handler(s)
DEDICATED SERVER established:0 refused:0
LOCAL SERVER
DISPATCHER established:0 refused:0 current:0 max:1022 state:ready
D001 <machine: WK0-KMA-DEV-NT4, pid: 338>
(ADDRESS=(PROTOCOL=tcp)(HOST=wk0-kma-dev-nt4.intern.dd.dk)(PORT=1196))
DISPATCHER established:0 refused:0 current:0 max:1022 state:ready
D000 <machine: WK0-KMA-DEV-NT4, pid: 337>
(ADDRESS=(PROTOCOL=tcp)(HOST=wk0-kma-dev-nt4.intern.dd.dk)(PORT=1195))
The command completed successfully
In the case above is the listener named “listener” (the default value) and there is no database explicit specified in the listener SID_LIST_<listener> in the listener.ora file.
To check that the connection is established in shared mode you can query services again and check if the established counter for one of the dispatchers has been increased.
The listener.ora file used in the above shown example look like:
# LISTENER.ORA Network Configuration File: D:\ORACLE\NETWORK\ADMIN\listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = wk0-kma-dev-nt4)(PORT = 1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = WK0KMA))
)
)
PASSWORDS_LISTENER= (oracle)
From Axapta point of view you don’t have to change anything to utilize the new setup at the database unless you for some reason wants to connect to the database in dedicated mode. To do so you have make a new entry in your tnsnames.ora file where you (SERVER=DEDICATED) in your CONNECT_DATA section for that entry.
AXDBTCP.WORLD = (DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(Host = dbserver)(Port = 1521))
)
(CONNECT_DATA = (SID = AXDB)(SERVER=DEDICATED))
)
Be aware that for Oracle databases running on a Windows server is TCP/IP the only supported protocol for multithreaded connections.
Published April 15, 2008 | Uno de los principales problemas que se plantean al implementar facturas o informes es como imprimir verticalmente por regla general es imposible en impresoras matriciales ya es una odisea. Si nuestro cliente es muy pero q muy “rata” o “cicatero y no quiere entrar en la era de las nuevas tecnologías con una impresora láser o estamos atados por una ISO que nos obligue a dar formatos extraños a la factura, podemos utilizar las dll’s del sistema para acceder a los documentos e incluso voltear o girar las fuentes de impresión para imprimir el famoso registro empresarial de las facturas.
Published April 7, 2008 | Buenas a todas y a todos. Por regla general las secuencias de facturación suelen configurarse y no dar problemas, pero en el caso que nos ocupa tenemos una multinacional que utiliza unos terminales de venta para generar facturas y albaranes etc, con numeraciones propias y esto hay que trasladarlo al AX con el minimo de problemas y de accesos a base de datos.
Nada de soluciones Salomónicas de update a “cholones” contra la custinvoicejour y cosas así que se os ve la pinta de “programatas” de medio pelo salidos de la vieja escuela del “clipper 5″, ahora el famoso “Delfi 6″. (jejejejej)
Bueno lo dicho aquí va el código para contabilizar facturas o albaranes con la numeración que queramos sin que el estándar de deje de chutar.
protected void insertJournal()
{;
ttsbegin;
numberSeq = this.allocateNumAndVoucher();
//axl numero de factura..
if (salesParmUpdate.invoiceid != ”)
{
number = salesParmUpdate.invoiceid;
numberSeq.parmNumberSequenceCode(”);
ttsbegin;
voucher = numberSeq.voucher();
ttscommit;
}
else
{
[number, voucher] = this.getNumAndVoucher();
}
if (this.updateNow())
{
this.postUpdate();
TransactionLog::create(this.transactionLogType(),this.transactionLogTxt());
ttscommit;
}
else
throw error(strFmt(“@SYS21533″));
}
Tan solo hay que sobre escribir el método insertjournal de la salesformletter
Published March 27, 2008 | 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
Published March 10, 2008 | The concept of Axapta System Tables
Axapta system tables contain data that the Axapta kernel uses to control the behaviour of the kernel. Axapta system tables are created automatically by the kernel, when Axapta is started for the first time against an empty database or after a service pack upgrade.
Axapta system tables are in many ways treated as ordinary Axapta tables from the kernel’s point of view. They are synchronized in same way and inserts / updates of the tables are done in a similar way.
System tables are not company specific and do not have a “DataAreaId” column. Therefore, system tables are implicitly treated as if they belong to the “DAT” company.
All system tables (except “SqlSystemVariables”) have a “RecId” column, which is updated as an ordinary table belonging to the “DAT” company.
Some system tables has the following standard columns:
· MODIFIEDDATE
· MODIFIEDTIME
· MODIFIEDBY
· CREATEDDATE
· CREATEDTIME
· CREATEDBY
All system tables (except “SqlSystemVariables”) have a TableId. The TableId’s for system tables starts at 65508 and each field in a system table also has a Id that follows the normal rules for Id generation of FieldId’s. Please refer to the form “SysSqlDictionary” to see the mapping of system tables and TableId / FieldId.
Axapta system tables can’t be accessed or viewed directly from the AOT (Axapta Object Tree). Furthermore, you should not access the system tables Axapta application layer.
This document contains a description of the most important Axapta system tables, except the table “SqlSystemVariables” which is described in another document. The information in this document is not valid for the table “SqlSystemVariables”.
Description of Axapta System Tables
ACCESSRIGHTSLIST (TableId = 65526)
This table contains info about explicit granted access rights for the defined user groups.
Note: Until you have explicitly defined permissions for a table, access to tables is defined using Feature keys. Once you set restrictions on a particular table for a particular user group, all other groups automatically have No Access to that table. As this will seriously impact the way the system works, you are presented with a warning dialogue before any change takes effect. In the dialogue you must decide whether other user groups should have no access as the result of the change you are making, or if other groups should keep their present permissions.
|
Column |
Description |
|
GroupId |
Id of group for which the access right is valid. Entry must be found in system table “UserGroupInfo”. Type: Varchar2(5) Value: Admin: Administrator group Xxxxx: Other groups |
|
RecordType |
Type of access rights Type: Number(10) Value: 0: Table permissions 3: Feature key and menu permissions |
|
ParentId |
????? Type: Number(10) Value: |
|
Id |
Internal Id of element on which access rights is defined. Type: Number(10) |
|
UtilElement |
Name of element on which access rights are defined. Type: Varchar2(40) |
AccessType |
Granted access right Type: Number(10) Value: 0: No Access. Prevent access to the functional group. 1: Read. Allow the group to view data but not edit, add, or delete data. 2: Change. Allow the group to view and edit data but not add, or delete. 3: Add. Allow the group to view, edit, add, but not delete data. 4: Full control. Allow the group to view, edit, add, and delete data. |
|
AccessTypeFkeyUse |
Access right granted through feature keys. Type: Number(10) Value: See AccessType |
COMMON
COMPANYDOMAINLIST (TableId = 65509)
This table contains relation between companies and domains.
DATAAREA (TableId = 65533)
This table contains data about created companies.
|
Column |
Description |
|
Id |
Id of company. Type: Varchar2(3) |
|
Name |
Name of company. Type: Varchar2(40) |
|
IsVirtual |
Indicates whether or not company is virtual or not Type: Number(10) 0: Real company 1: Virtual company. |
|
AlwaysNative |
Indicates whether or not data from company is stored in native files. Type: Number(10) 0: Stored in database. Always the case when running against an Oracle database. 1: Stored in native files. |
DATABASELOG (TableId = 65508)
This table contains data about which tables and events to log. The events are logged in the Axapta table SysDatabaseLog.
DOMAININFO (TableId = 65510)
This table contains data about domains.
PRINTJOBHEADER (TableId = 65525)
This table is used in connection with printing from Axapta.
PRINTJOBPAGES (TableId = 65524)
This table is used in connection with printing from Axapta.
SQLDESCRIBE (TableId = 65527)
This table is used temporarily during check / synchronisation process and should normally be empty.
SQLDICTIONARY (TableId = 65518)
This table contains data dictionary data about Axapta application and system tables (except SqlSystemVariables) as stored in Axapta data dictionary. Content of this table can be viewed by the form “SysSqlDictionary”
|
Column |
Description |
|
TableId |
TableId of table. Type: Number(10) Value: 1 – n 1 – 7999 Standard SYS layer. 8001 – 15999 GLS layer 16001 – 17999 DIS layer 18001 – 19999 LOS layer 20001 – 29999 BUS layer 30001 – 39999 VAR layer 40001 – 49999 CUS layer 50001 – 59999 USR layer 65513 – n: System tables When an object is initially created, Axapta automatically manages ids and assigns a new id according to the above table. Note, though, that when you modify an existing object, the object keeps its original id and is not assigned a new id in your layer. |
|
FieldId |
FieldId of field. Type: Number(10) Value: 1 – n 1 – 7999 Standard SYS layer. 8001 – 15999 GLS layer 16001 – 17999 DIS layer 18001 – 19999 LOS layer 20001 – 29999 BUS layer 30001 – 39999 VAR layer 40001 – 49999 CUS layer 50001 – 59999 USR layer 61440: ModifiedDate 61441: ModifiedTime 61442: ModifiedBy 61443: ModifiedTransactionId 61444: CreatedDate 61445: CreatedTime 61446: CreatedBy 61446: CreatedTransacrionId 61448: DataAreaId 65534: RecId 65513 – n: System fields |
|
Array |
Number of array elements in field Type: Number(10) Value: 0 – n 0: Table description entry 1: Field is a normal field > 1: Field is a array field |
|
Name |
Axapta name of object (table / field) Type: Varchar2(40) |
|
SqlName |
SQL name of object (table / field) Type: Varchar2(40) |
|
FieldType |
Type of field. Type: Number(10) Value: 0: String, Table entry 1: Integer, Time 2: Real 3: Date 4: Enum 7: Container 8: MemoString |
|
StrSize |
Size of string. Only relevant for STR fields. Type: Number(10) Value: 0 – 1000 0: Non Str field n: Str field |
|
Shadow |
Not in use. Type: Number(10) Value: 0 |
|
RightJustify |
Is field right justified? Only relevant for STR fields. Type: Number(10) Value: 0: Field is left justified or field type not STR 1: Field is right justified. |
|
Nullable |
Is NULL allowed for field at the Oracle database. Type: Number(10) Value: 0: NULL value not allowed. 1: NULL value allowed. Only container and Memo string. |
|
Flags |
Flag field. Currently only used for STR fields. Type: Number(10) Value: 1,2 1 (Bit 0 = 1): Field is DataAreaId 2 (Bit 1 = 1): Field is ordinary STR field |
SQLPARAMETERS (TableId = 65517)
This table is for future use.
SQLSTATISTICS (TableId = 65513)
This table is for future use. It is planned to store Axapta specific statistic data, which can help the kernel to optimize the parse, bind, execute and fetch operations.
SQLSTORAGE (TableId = 65515)
This table contains Oracle storage parameters as specified in Axapta “Storage Setup” utility. The value are added to the CREATE statement, whenever a database object is created from Axapta.
|
Column |
Description |
|
Id |
Id of storage paramter entry. Type: Number(10) Value: 0,1 0: Entry for a specific storage parameter. Used for display purposes. 1: Entry contains all storage parameter for the object. Used for generating CREATE statements. |
|
ObjectType |
Type of Object. Type: Number(10) Value: 0,1 0: Table 1: Index |
|
TableId |
TableId of table to which the object is related. Type: Number(10) Value: 0 – 65512 0: Default for object of ObjectType n: TableId |
|
IndexId |
Index number for table with TableId. Type: Number(10) Value: 0 – n 0: If ObjectType = 0 or TableId = 0 n: If ObjectType = 1 and TableId <> 0 65535 : Index RecId |
|
OverRide |
Not used. Type: Number(10) |
|
Parm |
Name of storage parameter. Type: Varchar2(25) Value: Null: Id = 1 Tablespace: Id = 0 and Tablespace specified Initial: Id = 0 and Initial specified Next: Id = 0 and Next specified Minextents: Id = 0 and Minextents specified Pctincrease: Id = 0 and Pctincrease specified Initrans: Id = 0 and Initrans specified Maxtrans: Id = 0 and Maxtrans specified Pctfree: Id = 0 and Pctfree specified Pctused: Id = 0 and Pctused specified |
|
Value |
Value of entry for the specified object. Type: Varchar2(255) |
SQLSYSTEMVARIABLES
The SQLSystemVariables table is not viewable from with Axapta; however, you can look at the contents by looking at the Database Information form.
SYSCONFIG (TableId = 65514)
This table contains license information, version, feature key setup and other basic system configuration data.
|
Column |
Description |
|
ConfigType |
Type of configuration information. Type: Number(10) Value: 0 – 4 0: License Name 1: License Serial number 2: Module license code 3: Feature key info 4: Service Pack Info 5: ??? |
|
Id |
Specific configuration information of give type. Type: Number(10) Value: Dependent of ConfigType 0: License Name Always 0 1: License Serial number Always 0 2: Module license code License code entry number 3: Feature key info Feature key entry number, which is not activated. 4: Service Pack Info 1 = Current Service Pack > 1 = Used to control the upgrade process |
|
Value |
Value of given configuration information. Type: Varchar2(40) |
SYSLASTVALUE (TableId = 65528)
This table is used to store set values for specific program elements for individual users, which should survive from session to session. This table is used by both the kernel and the application.
|
Column |
Description |
|
UserId |
Name of Axapta user for which this set up is stored. Type: Varchar2(5) |
|
RecordType |
Type of record Type: Number(10) Value: ????? |
|
ElementName |
Name of program element. Type: Varchar2(40) |
|
DesignName |
Design name of program element. Type: Varchar2(40) |
|
IsKernel |
Is set up kernel or application specific. Type: Number(10) Value: 0,1 0: No 1: Yes |
|
Value |
Value of the stored setup. Type: BLOB |
SYSTEMRECORDLEVELSECURITY (New for version 3.0)
This table contains info about record level security based on table, user and company. The stored information is the extra where condition for the table.
SYSSEMAPHORE
This is a virtual system table that is created and maintained by the kernel. The table can’t be found on the database; however, it contains data about all kernel semaphores
SYSTEMSEQUENCES (TableId = 65516)
This table contains sequence numbers for RecId and TransactionId. A row for each used company and sequence.
|
Column |
Description |
|
Id |
Type of sequence. Type: Number(10) Value: -1, -2 -1: RecId sequence -2: TransactionId sequence |
|
NextVal |
Next sequence number (value) to be drawn from the sequence. Type: Number(10) Value: Before version 2.5 : 1..2147483647 From version 2.5 : 1..2147483647, -2147483647..-1 From version 2.5 the next value for the sequence is wrapped around at value 2147483647 to –2147483647 For RecId sequences this value is updated by 25 for each drawing of a new number by the Axapta kernel. For TransactionId sequences this value is updated by 20 for each drawing of a new number by the Axapta kernel. |
|
MinVal |
Minimum value of sequence Type: Number(10) Value: 1 |
|
MaxVal |
Maximum value of sequence Type: Number(10) Value: Before version 2.5 : 2147483647 From version 2.5 : -1 |
|
Cycle |
Can the sequence loop around (cycle) Type: Number(10) Value: 0, 1 0: No 1: Yes |
|
Name |
Name of sequence Type: Varchar2(20) Value: RECID: RecId sequence TRANSID: TransactionId sequence |
|
DataAreaId |
Company for which the sequence is defined Type: Varchar2(3) Value: DAT: Used for DAT company and system tables xxx: All other companies including virtual companies. |
TABLECOLLECTIONLIST (TableId = 65532)
This table contains data about relation between virtual companies and table collections
|
Column |
Description |
|
VirtualCollectionArea |
Id of virtual company. Type: Varchar2(3) |
|
TableCollection |
Name of table collection attached to the virtual company. Type: Varchar2(40) |
USERGROUPINFO (TableId = 65530)
Table contains name for the defined user groups
|
Column |
Description |
|
Id |
Id of user group. Type: Varchar2(5) |
|
Name |
Name of user group. Type: Varchar2(45) |
USERGROUPLIST (TableId = 65529)
Table describes relation between users and user groups.
|
Column |
Description |
|
UserId |
Id of Axapta user Type: Varchar2(5) |
|
GroupId |
Id of group. Type: Varchar2(5) |
USERINFO ((TableId = 65531)
Table is used to store general set up values for individual users. Use the “Tool/Options..” menu-item to change values in this table. If “UserInfo” is empty or entry for current user doesn’t exists, then no menu item or toolbar is available from Axapta.
UTIL* (UTILAPPLHELP, UTILCODEDOC, UTILELEMENTS, UTILELEMENTSOLD, UTILIDELEMENTS, UTILIDELEMENTSOLD, UTILLOCKS)
These are all virtual tables containing info about programming elements.
VIRTUALDATAAREALIST (TableId = 65534)
This table contains data about relation between real companies and virtual companies.
|
Column |
Description |
|
Id |
Id of company. Type: Varchar2(3) |
|
VirtualDataArea |
Id of virtual company. Type: Varchar2(3) |
Published March 6, 2008 | 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.
Published February 19, 2008 | Args es utiliza para pasar argumentos al constructor de una clase. Args pueden transmitir información como el nombre, y los parámetros que llaman a una nueva clase.
Los formularios, informes y consultas utilizan la clase Args como primer argumento en el constructor.
Pasandole el nombre del objeto a crear a una clase args y despues llamar a classfactory con estos argumentos podemos inicializar fomularios, informes etc.
Args a = new Args(“CustTable”);
formRun fr = ClassFactory.FormRunClass(a);
fr.init();
fr.run();
para recuperar el objeto args en la clase de destino, por regla general existe un metodo que nos devuelve este dato.
elment.args() en el caso de formulario.
El objetivo de esto es poder pasar a traves de args objetos completos a otros contextos de ejecución de forma que podriamos abrir un formulario inicial F1 ejecutar otro formulario secundario F2 y poder ejecutar metodos del formulario 1 desde el formulario 2.
un ejemplo.
Hemos creado un from con un metodo para recuperar el texto de un strignedit y este texto lo vamos a pintar desde un report, utilizando para ello una clase intermedia o el metodo del form que lo ha llamado.
public void init()
{
object ob;
FIR_ReportClas FIR_ReportClas;
super();
//axl si no es la clase entonces es el formmm…
if (classIdGet(element.args().caller()) == classNum(FIR_ReportClas))
{
FIR_ReportClas = element.args().caller();
print FIR_ReportClas.texto();
}
else
{
ob = element.args().caller();
print ob.texto();
}
Posted in 3.0, 4.0, aot, axapta, desarrollo, dynamics, Uncategorized, x++ | 
aot, axapta, desarrollo, froms, x++ | 
Leave a commentPublished February 15, 2008 | Desde este blog apostamos más por la utilidad y el buen hacer que por las facturas que van a cobrar las consultoras en ventas de productos Microsoft. Hemos de reconocer que AX es un buen producto como “erp” que ya se ha asentado en nuestro país y que día a día es una solución tanto para la pequeña como media empresa.
os_authent_prefix
Con un prefijo tipo ‘ops$’ nos sevira, de manera que oracle sepa identificar si el usuario del SO que solicita la conexión esta creado en oracle autorizando el acceso.
-- Windows
CREATE USER "OPS$DOMINIO.COM\DBO" IDENTIFIED EXTERNALLY;
GRANT CONNECT TO "OPS$DOMINIO.COM\DBO";
Crearemos un usuario en nuestro dominio en este caso DBO .
Posted in 3.0, 4.0, axapta, dynamics, oracle, Uncategorized | axapta, Instalación, oracle | Leave a comment