originating server.
the second ack is a separate message.
> The bigger scope is that I can Identify at the top Tier computer, the
> transaction from the POS device in any store.
>
> Since this is done under https (ssl) the data is encrypted.
>
> The receive side is a event class that captures the xml transmitted,
> Identifies it saves it to a file with the Identity name.
> The reason is that it is the fastest way to capture and store a high
> volume of these. all the xml files that have the same structure go to
> the same URL.
> A service then reads the XML files and processes them.
> then sends a Ack back to the sending tier.
> the orginal tier that send it then marks that message sent and recieved.
>
>
> I have added services that created the xml to be sent and sends them to
> a url. Currently have the URL in a property file that identifies the
> tiers it is to send its messages to. This is read every time a message
> is sent so tiers can be added on the fly. eventually make make it into
> the entities.
> the messages are kept in an entity till an Ack is received then if a
> flag is set it is deleted.
> The ones not deleted are audit trails to verify that all critical
> messages were in fact sent, Should an error arise in one of the tiers.
>
> I don't see a need to open an other port since it is the controller that
> is used to direct the messages.
>
>
>
> Skip sent the following on 9/24/2007 5:10 PM:
>> So, BJ, I have read this again and I wonder if you could clarify. You are
>> NOT using the ofbiz synchronization. Instead, you are using a custom XML
>> transmit from the remote store to the central database with a special url
>> and then getting xml back from the POST.
>>
>> Is this correct? I ask because I was considering something similiar only I
>> was going to write a little module that lived in the server and opened
>> another ssl port exclusively to process these XML queries from remote
>> stores.
>>
>> Skip
>>
>> -----Original Message-----
>> From: BJ Freeman [mailto:
[hidden email]]
>> Sent: Tuesday, September 18, 2007 4:53 PM
>> To:
[hidden email]
>> Subject: Re: POS Setup- with tiers
>>
>>
>> if you following what david has proposed, forget what i said.
>>
>> Vince Clark sent the following on 9/18/2007 4:50 PM:
>>> Am I making this too complicated? I just need to understand how the OOTB
>>> entity sync works. Nothing custom. The documentation states pretty
>>> clearly that it does work, although my summary of the steps left out
>>> much detail. That is what I am trying to fill in.
>>>
>>> More simply put:
>>> How do I make a POS terminal communicate with a store server
>>> How do I make a store server communicate with a central server
>>> And back down the stack from central server to POS terminal
>>>
>>> Since my original post I have been reviewing the example
>>> PosSyncSettings.xml file. I don't see anything in this file that
>>> specifies a host name. So I assume the only place to tell an instance
>>> what server to talk to is in the serviceengine.xml file.
>>>
>>> I will also review the entity related training videos. Unfortunately I
>>> don't have much time for learning curve on this effort.
>>>
>>> BJ Freeman wrote:
>>>> There is a lot more to this than you have described.
>>>> there is no defined way to do what you have describe, to my knowledge.
>>>> then again, someone may have slipped it in with out my knowing
>>>>
>>>> when I proposed this sometime ago, I left the actual way to communicate
>>>> open.
>>>>
>>>> All the services that were used to communicate called one service that
>>>> was the actual service for sending the data to the next level. up down
>>>> or both. so I plugged in the communications to update services that were
>>>> already in place, and added updates for the stuff updates services I
>> added.
>>>> I opted, since I already use ssl xml communications from other stores,
>>>> to keep that form of communications between levels. I use different
>>>> URL's for the different functions as a way to put them thru the
>>>> controller and into the events.
>>>>
>>>> Since then I have defined two communications 1)non urgent updates 2)
>>>> real time updates. Real time updates for things like pos transactions so
>>>> the product is put in reserve till the pos sale is complete then an
>>>> order is completed. this reduces problems with out of stock.
>>>> Using the same code for holding a item but a type is added to "holding
>>>> for POS". also the inventory updates are realtime both directions. so
>>>> far have not run into overlap, but I believe with a big enough system,
>>>> that will happen.
>>>> Non urgent are for stock reorder and transfers.
>>>>
>>>> for the purist I assume they will opted for SOAP or XMLRPC.
>>>>
>>>> Since stores can be defined at each location and the prefix to the order
>>>> can be unique the only consideration is the key size at the top level so
>>>> it can keep all the orders for all the stores.
>>>> I can see the key size needing to be increased considerable in a large
>>>> system, for order entity.
>>>>
>>>> so each POS is a mini store
>>>> so you have Store(ID)POS(id) as a prefix to the top level.
>>>> and POS(id) to identify which POS terminal it came from at the store
>>>> level. so you can see that Key for the orders can be large for a
>>>> national chain.
>>>>
>>>> at the top level I use facilities to define the stores and this is where
>>>> the communication is setup to the lower level.
>>>>
>>>> I am still working on the code that initializes a new store and new POS
>>>> in the store from the upper levels.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Vince Clark sent the following on 9/18/2007 2:49 PM:
>>>>
>>>>> I am having trouble figuring out the "step by step" process to deploy
>>>>> POS with synchronization.
>>>>>
>>>>> First area of clarification - How do I get the various pieces deployed
>>>>> and talking to each other? I have reviewed all the documentation I can
>>>>> find, and also the related config files. Here is what I understand so
>> far:
>>>>> 1) Setup all the necessary entities (stores, facilities, products,
>>>>> pricing, etc.)
>>>>> 2) Create POS sync settings to define what entities will be synced
>>>>> (example PosSyncSetting.xml)
>>>>> 3) Define terminals per example DemoRetail.xml
>>>>> 4) Set entity-sync-rmi in serviceengine.xml file
>>>>> 5) Schedule the sync service
>>>>>
>>>>> So where do I do each of these? Master server, per store server, pos,
>>>>> all of the above? For example, if I have a configuration of one store,
>>>>> one pos terminal in the store, and one central server I want the flow to
>> be:
>>>>> Push product, pricing, etc from central server down to POS terminal:
>>>>> MCS -> PSS -> POS
>>>>>
>>>>> Pull transactions from POS terminal to MCS:
>>>>> POS -> PSS -> MCS
>>>>>
>>>>> So let's start with the central server as the majority of setup will
>>>>> occur here. The main question I have about the central server is, how
>>>>> does it know where to "Push"? There is only one setting in
>>>>> serviceengine.xml for entity-sync-rmi. So how do I configure multiple
>>>>> per store servers? Or do I misunderstand the use of "PUSH" in the config
>>>>> file? Is everything really "Pull?" So we just point each deployment to
>>>>> the server where it should communicate? For example the POS terminal
>>>>> would always be configured to talk to the PSS, PSS to MCS?
>>>>>
>>>>> Is it necessary to use a PSS, or can we go straight from POS->MCS?
>>>>>
>>>>> And for those of you also trying to come up to speed on POS, here is the
>>>>> glossary:
>>>>> MCS = Main Central Server
>>>>> PSS = Per Store Server
>>>>> POS = Point of Sale
>>>>>
>>
>>
>>
>
>
>