re : replicated and central object

[ekben]

dear sully1,
i come across your post and its really a helpful post.
i just want to confirm few thing.
1)central objects are spec in rdb format sitting in database in enterprise server plus c component in deployment server in all the pathcodes. may i know what should i call the c component in local fat client?
2)u said tam from central object spec and dll from c component. may i know the c is in deployment, right? again, what happen to local client c component in source folder, include folder, obj folder?
3) you mean local client bin32(dll) build from c, right? the c from local or deployment.
4) what happen to bin32 folder in deployment server?

thanks alot
ben

 

[kiyer_2000]

Hello,
I find the above questions repeated lot many times. I shall try to clarify the above questions.
(A1)The C components on the local machine will also be called as replicated objects. Note that, these C files will be used by the local machine only when a developer is trying to create/modify any object on that machine. A production user will never need or use the C files in the local machine.
(A2) The answer is again the same as above. The local .C and .H will be used only when some development is going to take place in that machine.
(A3) When you run a busbuild, the .C file will be used to create a new dll file. Now you can run the busbuild either on a local workstation (This is when a developer is trying to busbuild on the workstation) or on the Deployment server (This is when we build a package on the Dep Server)

(A4) When ever you login to say PD7334 environment on the Deployment server, then the applications will use the dll files located on the directory
/jdedwardsoneworld/PD7334/bin32. These dll files will not be used on any other occassion.

Regards,
Karthik Iyer

 

[ekben]

thanks alot, karthik. few points to confirm with you.

1).c and .h files in local machine include and source folder will only be used when development. user will never use these even though sitting in their local machine, right?
2)only when package build, dll file will be created from .c and .h, right?
3)during package build, central object will be distributed to local spec folder and .c and .h will be distributed to bin32 folder. .c and .h can be from local or server depending on package build from which one, right?
4)can give example of dll object and object in spec folder used in the jde?
5)what about obj folder?

thanks again.
ekben

 

[ekben]

can explain a bit? thx

dear all,
thanks

 

[kiyer_2000]

Re: can explain a bit? thx

(A1) Right. User will not never use the .C and .H files on the local workstation
(A2) dll's will be created during busbuild. This busbuild can be started independently or through the Package build process. If it is Package build, it will create a new set of dll's on the Dep Server. If it is independently called on a workstation, it will replace the dll of only the workstation.
(A3) During package build, the .C and .H files of the Dep Server pathcode WILL ONLY be used. It does not matter from where you start the package build process.
(A4) i did not get your question
(A5) OBJ files are an intermediate files created during busbuild before actually creating the dlls. They are not required for an end user. It is used only while doing a busbuild.

Hope I was clear to some extent.
Regards,
Karthik Iyer

 

[ekben]

thanks. can explain further

hi kiyer,
thanks alot.
1)can i say only when 1 2 do deployment or build package then only will make use of the deployment server?
2)may i know all the objects(report/screen/bfsn,...) i create in omw in fat client (my own workstation) will keep in which folder in local pathcode? let say my pathcode is PY7334. is it in tam in spec folder? what about .c and .h?
3)what sort of program in .c and .h source code? i notice there are business function also. if i create business function it will be in .c and .h or what?
4)when we check in our report that created locally, the source(tam or replicated object) will be also in spec folder in deployment server and later package build to server and store as central object in database, right?
5)what about business function we build locally? in local pc is stored in spec folder or source and include folder? later if i check in the business function to deployment server, where it store there?

thanks again.

 

[ekben]

can help?

dear all,
can explain my last post questions in the subject "thanks, can explain further"?

thanks

 

[ekben]

appreciate

can explain my last post questions in the subject "thanks, can explain further"?

rgds
ekben

 

[ekben]

Re: appreciate

dear all, can explain the follow?

1)can i say only when 1 2 do deployment or build package then only will make use of the deployment server?
2)may i know all the objects(report/screen/bfsn,...) i create in omw in fat client (my own workstation) will keep in which folder in local pathcode? let say my pathcode is PY7334. is it in tam in spec folder? what about .c and .h?
3)what sort of program in .c and .h source code? i notice there are business function also. if i create business function it will be in .c and .h or what?
4)when we check in our report that created locally, the source(tam or replicated object) will be also in spec folder in deployment server and later package build to server and store as central object in database, right?
5)what about business function we build locally? in local pc is stored in spec folder or source and include folder? later if i check in the business function to deployment server, where it store there?

rgds
ekben

 

[kiyer_2000]

Re: appreciate

(A1) Yes. The Dep Server will be used mainly for package related activities. But there are other activities which may be rare such as applying esu, upgrade of the installation, license renewing etc which will be done on the Deployment Server.
(A2) When ever you create a new business function say in Py7334 pathcode, the .C and .H will be first created in your local workstation. When you do a check in, these two files will be copied to the PY7334\include and PY7334\source folders inside Deployment Server. When you build a full package, these files will be copied to the packagename\include and packagename\source folders. Upon deploying this package to a workstation, these files will be copied to the local Py7334\include and Py7334\source folder. This is the flow of how a .c file created in workstation1 is deployed to other workstations.
(A3) The creation of .C and .H is done internally by jde. There is not much we can do in the process of the .c file creation. But the functions written using the VC editor can be modified or viewed by the user by directly opening the .c file. This is of course not advised. It has to be done using the frontend omw tool of jde.
(A4) This question is answered in A2
(A5) This question is answered in A2

 

[ekben]

Re: thanks. final asking

thanks kiyer, this is last.

1)may i know if only program and business function in .c and .h?
2)what about data structure, menu, form, report, business view all these objects? they stored as what?
3)i know dll built from .c. may i know if only business function and application program in dll?
4)local or deploy server spec folder (tam format) from central object in database (rdb format). may i know what object in spec folder? not business function and application program, right?

thousand thanks.

 

[kiyer_2000]

Re: thanks. final asking

Hello,
(A1) Only BSFN's and Tables will have a corresponding .C and .H files. The rest are stored in the database central object tables.
(A2) As i told you, they do not have a physical file in Dep Server. They lie inside the database.
(A3) Yes. business functions are bunduled into dlls. Applications or reports only use these dlls. They are never converted into dlls.
(A4) Any other object which is stored in the database, needs some physical file existance.This will get jitted down to the spec folder as .ddb and .xdb files (Both Dep Server and Workstation). Note that these files will grow in size as and when you try to open new applications/Reports. But the number of files will not increase.
This is the actual conversion of RDB format into TAM format.

Hope i was able to clarify your doubts.

Regards,
Karthik Iyer