Database isn't open somehow.

[ids]

From this Provide XML log file, PRV_inline.log, getting this message:

Store Fatal Error: MER-TUI-DTB-00322: Database 'Merchant' is not open

Why is this DB not open?

Hoping the answer will point me in the right direction.

Note: using the PRV_Action_ProvisionStringData(l.settings:provisio n:xml) function to run some XML updates on inventory.

Thanks,

Scott

[Kent Multer]

Sometimes a look in the LSK will provide some helpful clues. But sometimes Merchant seems to throw error codes that are misleading.

The -TUI- in your error indicates a problem detected in the template UI. The -DTB- tells us it will probably be in the file features/tui/tyi_db.mv. I don't know why an XML inventory update would need to manipulate templates ... maybe your code is operating in the shopping-page world, when you meant for it to run on the admin side?

[ids]

This module is running completely in the Admin ==> Utils. There are no template functions being called in my module.

More Info: When I write the var containing the XML to a file and import to the XML import module in Data Management, I see this issue:

Import of wildcard_admin_xmloutput.xml failed: MER-IMP-RND-00001: The import operation terminated unexpectedly.

So, two different errors.

Note: The XML had been validated.

Scott

[ids]

Okay, this is strange stuff. The TUI error message and IMP-RND seem to be random errors thrown at me. They are related to any sort of XML Import function. Make me wonder if there is something screwy with the dev store I'm working from.

The TUI error is found in a Branch ID function. And I have no recollection of what function or feature the RND refers to. I can't find that in the 10.06 LSK. Any guesses as to what maybe going on?

Scott

[dcarver]

You should try avoid using PRV_Action_ProvisionStringData. If you are updating product inventory you should look into using the JSON API.

[ids]

???

I don't think there is a JSON API equivalent to this is there?

Scott

[dcarver]

The Product_Update API function takes Product_Inventory as an input parameter

[ids]

Sorry, forgot to post the XML update needed:

<Product_CustomField module="baskinv" field="total_inv" product="shirt">500</Product_CustomField>

If you've assumed that's what I meant, is that because the Product_Update function has finally been enhanced to take basket counts into consideration. It's been a while since I've looked at this function in the LSK. Looking at 10.06 Product_Update, I don't see where it handles the potential counts in a basket.

Scott

[dcarver]

You could use the Product_Update API function and pass a request such as

{
    Edit_Product: 'shirt',
    CustomField_Values:
    {
        baskinv:
        {
            total_inv: 500
       }
   }
}  

[ids]

How does this request, the JSON string(?), get passed?

Scott

[dcarver]

You could use one of the API SDKs, such as PHP, Python, NodeJS, etc... where you could build such a request and send it. But yes, that example above sends the data as a JSON object.

[ids]

So, I have this module done until I ran into this DB not open issue. The Provide XML tags should work. I'm using as documented. And they work in another part of the module. I don't know why I shouldn't use the PRV_Action_ProvisionStringData function. What is the issue with this?

Also confused why I need to use an SDK to run a function that is in a scheduled task as well as running the function manually in a Utils screen tab. OR, That means using mvcall to call a system screen or mystore.com/json.mvc to be able to process s.json_data? Your suggestion would be to submit that JSON snippet above? What JSON API function will process the s.json_data?

I have to pre-follow-through here. kinda looking ahead I guess. Your sample snippet has one product. I'm looking at over 3K products per on this project. Is there a different structure to the object or will it be your sample JSON string repeated 3k+ times? The other part of this, if the product doesn't exist what happens? Is it ignored and moves on to the next one? Or, will the process STOP processing the string?

[dcarver]

We don't recommend using PRV_Action_ProvisionStringData because it requires adding additional top-level tags, such as the Store tag and if you ever use it for user inputted data and are not careful, they could break out of the Store tag and run unauthenticated Domain level tags. Basically it's a security risk and we may end up deprecating it in the future.

You don't have to use an SDK, I was unaware you are doing this in a Scheduled task. All JSON API functions will process s.json_data.

What exactly are you trying to do? You talk about 3k products but what are you doing? How is this stuff needing to be updated? The JSON API supports multi requests where you could send multiple requests to be processed at once.

[ids]

Here are the steps in the scheduled task or clicked button in Utils:
- MvCall grabs the inventory data from a server in the warehouse (In Utils I need to use MvAnync)
- decode the JSON response -- contains all the products (3k) into a structured array (not a Miva product friendly array to remap)
- running a ForEach loop to populate the XML tags
- run the XML to update the inventory.

The XML I'm running looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<Provision>
   <Store code="ids">
      <Product_CustomField module="baskinv" field="total_inv" product="XX001-20">1</Product_CustomField>
      <Product_CustomField module="baskinv" field="total_inv" product="XX001-40">2</Product_CustomField>
   </Store>
</Provision>

This should work IMO.

Scott

[ILoveHostasaurus]

Can the server in the warehouse do an API call when inventory on a given product changes? Even better is it tracks what is in need of updating, or a script running on that server does, and sends batches of updates using the API multicall functionality for more efficiency by bundling the update deltas into one or a few API hits instead of one per product. Doing it that way:

• Eliminates the security risk of opening the warehouse computer to an outside hit,
• If you try to solve the above problem via firewall rules, it will possibly still break at some point if the source IP of the outbound requests from the site change, or end up load balanced, which may occur.
• If the above stops working, it's not likely someone will notice until out of stock products are sold, but monitoring could go on the warehouse server side to alert if an outbound request has failed.
• It sounds like the proposed way is going to be subjecting the store to updates of large quantities of data that often will have not changed, which creates performance and scalability issues
• It's using a method of updating that David pointed out is a risk, as well as subject to not being supported in the future because of risks like that, which means this could break without warning for a second reason.