I wanted to demonstrate using the Any OpenEAI AnyERP Service (Gateway) as a generic object store. Do you know if we already have that deployed anywhere?
Ideally, what I’d like to do is to get this deployed in DEV and QA and have it called something like ObjectStoreService. Tod can you think of a better name than that? Then I’d like to take the existing test suite from the sample enterprise and get it deployed as the ObjectStoreServiceTestSuiteApp or something similar. Then I would like to demonstrate how we could send requests through HAPS for compliance-related objects and get our HIPAA audit logs.
Tod, let me know if this makes sense to you as a demo of an easy-to-use object store. The process I wanted to demo to Chuck Johnson is how they could model and object, add it to the MOA and then make this ObjectStoreService authoritative for it. The think he would like to eliminate is the need to create custom databases for things.
He also wants to do the same thing for files—like PDFs and that looks a lot like what we did for DICOM objects or PEAR, but I need to look at both of those old examples to refresh my memory on exactly what we did.
IF you want to go ahead and configure HAPS in DEV to proxy BasicPerson and audit for that one object, which I know the AnyErpService should support then go ahead and do that too. That will make it easy to demonstrate that one aspect of this. Thanks!
It would be good to be able to demo this next week…so have it in both DEV and QA. One thing I forgot to mention is that I think we need a web service façade for this as well. So I think use case for the object store service would be that the workflow folks would consume WSDL and send requests to the web service façade and the web service façade would send requests to the ObjectStoreService unless the object requires HIPAA audit logging and, in which case, we would route the message through HAPS and then to the ObjectStoreService. Does that make sense?
I also think I am going to need to define a new generic object unless we have one already, because there are kind of two levels of goals they are trying to achieve. 1) be able to define any new object without creating a database and use it (we can do that now, but there are deployment changes) and also store new objects without any deployment changes. So I think we need a new object that is completely generic like a object with name value pairs and the name of an application it is associated with. I can work on adding that to a MOA and we can add that all in place once you get this deployed.
After some thought on this, I think we should take this back to using the generalized command that stores these objects as serialized XML objects with a key value. If you want to you can leave the RDBMS command deployed in the service and we can retain that as an alternative approach. I think one advantage of the RDBMS approach now over the serialized object store approach is that one can actually query for objects with other fields than their key values, right?
I think in a generalized object store we are going to have to address that in some way and, more importantly, partition the store by requesting application. That means a couple of things—storing the name of the application that owns the object in the database and in the service including the name of the object owner in the request and returning only objects that belong to that owner. One way to do that might be to have a boolean parameter stating whether or not the command will use SenderAppId as the app owner or not. This would allow the same command to be used to return only objects of the owner or all objects, depending on how the command is configured.
So I think we should try and work these features into the AevRequestCommand and we might want to create a new command based on it called the ObjectStoreCommand and treat this as a new OpenEAI Service. We should probably ask Tod to confirm what the best starting point for this service is—for example, is there an OpenII version of this that might have more features and you can go from there.