ਮਲਟੀਟੇਨੈਂਸੀ ਬਾਰੇ

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਸ਼ਬਦ ਵਿੱਚ ਇੱਕ ਚੰਗਾ ਰੂਸੀ-ਭਾਸ਼ਾ ਐਨਾਲਾਗ ਨਹੀਂ ਹੈ। ਵਿਕੀਪੀਡੀਆ ਦਿੰਦਾ ਹੈ ਅਨੁਵਾਦ "ਬਹੁ-ਕਿਰਾਏਦਾਰੀ, ਮਲਟੀਪਲ ਕਿਰਾਏਦਾਰੀ।" ਇਸ ਨੂੰ ਕਈ ਵਾਰ "ਮਲਟੀਪਲ ਮਲਕੀਅਤ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਸ਼ਰਤਾਂ ਕੁਝ ਉਲਝਣ ਵਾਲੀਆਂ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਵਿਸ਼ਾ ਵਸਤੂ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕਿਰਾਏ ਜਾਂ ਮਾਲਕੀ ਨਾਲ ਸੰਬੰਧਿਤ ਨਹੀਂ ਹੈ। ਇਹ ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਇਸਦੇ ਸੰਚਾਲਨ ਦੇ ਸੰਗਠਨ ਦਾ ਸਵਾਲ ਹੈ। ਅਤੇ ਬਾਅਦ ਵਾਲਾ ਕੋਈ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ.

ਅਸੀਂ 1C:Enterprise ਵਿੱਚ ਕੰਮ ਦੇ ਕਲਾਉਡ (ਸੇਵਾ) ਮਾਡਲ ਲਈ ਇੱਕ ਪਹੁੰਚ ਡਿਜ਼ਾਈਨ ਕਰਨ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਦੇ ਹੋਏ ਉਸੇ ਸਮੇਂ ਮਲਟੀਟੇਨੈਂਸੀ ਦੀ ਸਾਡੀ ਸਮਝ ਨੂੰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਇਹ ਕਈ ਸਾਲ ਪਹਿਲਾਂ ਦੀ ਗੱਲ ਹੈ। ਅਤੇ ਉਦੋਂ ਤੋਂ ਸਾਡੀ ਸਮਝ ਦਾ ਲਗਾਤਾਰ ਵਿਸਤਾਰ ਹੋਇਆ ਹੈ। ਅਸੀਂ ਲਗਾਤਾਰ ਇਸ ਵਿਸ਼ੇ ਦੇ ਵੱਧ ਤੋਂ ਵੱਧ ਨਵੇਂ ਪਹਿਲੂਆਂ (ਫ਼ਾਇਦੇ, ਨੁਕਸਾਨ, ਮੁਸ਼ਕਲਾਂ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ, ਆਦਿ) ਦੀ ਖੋਜ ਕਰ ਰਹੇ ਹਾਂ।

ਕਈ ਵਾਰ ਡਿਵੈਲਪਰ ਮਲਟੀਟੇਨੈਂਸੀ ਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਵਿਸ਼ੇ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਝਦੇ ਹਨ: "ਕਈ ਸੰਸਥਾਵਾਂ ਦੇ ਡੇਟਾ ਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਸੰਗਠਨ ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਲ ਇੱਕ ਕਾਲਮ ਜੋੜਨ ਅਤੇ ਇਸ ਉੱਤੇ ਇੱਕ ਫਿਲਟਰ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।" ਅਸੀਂ, ਬੇਸ਼ੱਕ, ਇਸ ਪਲ ਤੋਂ ਇਸ ਮੁੱਦੇ ਦਾ ਆਪਣਾ ਅਧਿਐਨ ਵੀ ਸ਼ੁਰੂ ਕੀਤਾ ਸੀ। ਪਰ ਉਹਨਾਂ ਨੇ ਛੇਤੀ ਹੀ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇਹ ਸਿਰਫ ਇੱਕ ਕਲੀਅਰਿੰਗ ਸੀ (ਵੀ, ਤਰੀਕੇ ਨਾਲ, ਆਸਾਨ ਨਹੀਂ)। ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਇੱਕ "ਪੂਰਾ ਦੇਸ਼" ਹੈ।

ਬਹੁ-ਵਚਨ ਦਾ ਮੂਲ ਵਿਚਾਰ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਬਿਆਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਕਾਟੇਜ ਹੈ ਜੋ ਇੱਕ ਪਰਿਵਾਰ ਦੇ ਅਨੁਕੂਲ ਹੋਣ ਲਈ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ, ਜੋ ਇਸਦੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (ਦੀਵਾਰਾਂ, ਛੱਤ, ਪਾਣੀ ਦੀ ਸਪਲਾਈ, ਹੀਟਿੰਗ, ਆਦਿ) ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਮਲਟੀਟੇਨੈਂਸੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਬਿਲਡਿੰਗ ਹੈ। ਇਸ ਵਿੱਚ, ਹਰੇਕ ਪਰਿਵਾਰ ਇੱਕੋ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਪਰ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਪੂਰੇ ਘਰ ਲਈ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਕੀ ਮਲਟੀਟੇਨੈਂਸੀ ਪਹੁੰਚ ਚੰਗੀ ਜਾਂ ਮਾੜੀ ਹੈ? ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਬਹੁਤ ਵੱਖਰੇ ਵਿਚਾਰ ਪਾ ਸਕਦੇ ਹੋ। ਇੱਥੇ ਕੋਈ ਵੀ "ਚੰਗਾ ਜਾਂ ਬੁਰਾ" ਨਹੀਂ ਜਾਪਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਹੱਲ ਕੀਤੇ ਜਾ ਰਹੇ ਖਾਸ ਕੰਮਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਪਰ ਇਹ ਇੱਕ ਵੱਖਰਾ ਵਿਸ਼ਾ ਹੈ...

ਇਸਦੇ ਸਰਲ ਅਰਥਾਂ ਵਿੱਚ, ਮਲਟੀਟੇਨੈਂਸੀ ਦਾ ਟੀਚਾ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਖਰਚਿਆਂ ਨੂੰ "ਸਮਾਜਿਕ" ਦੁਆਰਾ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਣਾ ਹੈ। ਇਹ ਉਹੀ ਅੰਦੋਲਨ ਹੈ ਜਿਵੇਂ ਕਿ "ਆਰਡਰ ਕਰਨ ਲਈ" ਲਿਖਣ ਦੀ ਬਜਾਏ, ਉਤਪਾਦਨ ਹੱਲ (ਸੰਭਵ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲਿਤ ਅਤੇ ਸੋਧ ਨਾਲ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਲਾਗਤ ਨੂੰ ਘਟਾਉਣਾ। ਕੇਵਲ ਇੱਕ ਮਾਮਲੇ ਵਿੱਚ ਵਿਕਾਸ ਦਾ ਸਮਾਜੀਕਰਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਦੂਜੇ ਵਿੱਚ - ਸ਼ੋਸ਼ਣ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਦੁਹਰਾਉਂਦੇ ਹਾਂ, ਵਿਕਰੀ ਦੇ ਢੰਗ ਨਾਲ ਕੋਈ ਸਿੱਧਾ ਸਬੰਧ ਨਹੀਂ ਹੈ. ਮਲਟੀਟੇਨੈਂਸੀ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਾਰਪੋਰੇਟ ਜਾਂ ਵਿਭਾਗੀ IT ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਸਮਾਨ ਸ਼ਾਖਾਵਾਂ ਅਤੇ ਹੋਲਡਿੰਗ ਐਂਟਰਪ੍ਰਾਈਜ਼ਾਂ ਨੂੰ ਸਵੈਚਾਲਿਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ ਮਲਟੀਟੇਨੈਂਸੀ ਸਿਰਫ ਡੇਟਾ ਸਟੋਰੇਜ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨ ਦਾ ਮਾਮਲਾ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਨਮੂਨਾ ਹੈ ਕਿ ਕਿਵੇਂ ਐਪਲੀਕੇਸ਼ਨ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ (ਇਸਦੇ ਆਰਕੀਟੈਕਚਰ ਦਾ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸਾ, ਇਸਦੇ ਤੈਨਾਤੀ ਮਾਡਲ, ਅਤੇ ਇਸਦੇ ਰੱਖ-ਰਖਾਅ ਸੰਗਠਨ ਸਮੇਤ)।

ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਬਾਰੇ ਸਭ ਤੋਂ ਮੁਸ਼ਕਲ ਅਤੇ ਦਿਲਚਸਪ ਗੱਲ, ਇਹ ਸਾਨੂੰ ਜਾਪਦੀ ਹੈ, ਇਹ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਸਾਰ “ਬਾਇਫੁਰਕੇਟਸ” ਹੈ। ਕਾਰਜਕੁਸ਼ਲਤਾ ਦਾ ਹਿੱਸਾ ਖਾਸ ਡੇਟਾ ਖੇਤਰਾਂ (ਅਪਾਰਟਮੈਂਟਾਂ) ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਤੱਥ ਵਿੱਚ "ਰੁਚੀ ਨਹੀਂ" ਹੈ ਕਿ ਦੂਜੇ ਅਪਾਰਟਮੈਂਟਾਂ ਵਿੱਚ ਵਸਨੀਕ ਹਨ। ਅਤੇ ਕੁਝ ਘਰ ਨੂੰ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਮਝਦੇ ਹਨ ਅਤੇ ਇੱਕੋ ਸਮੇਂ ਸਾਰੇ ਨਿਵਾਸੀਆਂ ਲਈ ਕੰਮ ਕਰਦੇ ਹਨ। ਉਸੇ ਸਮੇਂ, ਬਾਅਦ ਵਾਲੇ ਇਸ ਤੱਥ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਇਹ, ਸਭ ਤੋਂ ਬਾਅਦ, ਵੱਖਰੇ ਅਪਾਰਟਮੈਂਟ ਹਨ, ਅਤੇ ਇਹ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਗ੍ਰੈਨਿਊਲਿਟੀ ਅਤੇ ਸੁਰੱਖਿਆ ਦੇ ਜ਼ਰੂਰੀ ਪੱਧਰ ਨੂੰ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ.

1C:Enterprise ਵਿੱਚ, ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਨੂੰ ਕਈ ਤਕਨੀਕਾਂ ਦੇ ਪੱਧਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ 1C:Enterprise ਪਲੇਟਫਾਰਮ, ਦੇ ਮਕੈਨਿਜ਼ਮ ਹਨ1C: ਪ੍ਰਕਾਸ਼ਿਤ ਹੱਲਾਂ ਲਈ ਤਕਨਾਲੋਜੀ 1cFresh"ਅਤੇ"1C: ਹੱਲ ਵਿਕਾਸ ਤਕਨਾਲੋਜੀ 1cFresh", ਵਿਧੀ ਬਸਪਾ (ਸਟੈਂਡਰਡ ਸਬ-ਸਿਸਟਮ ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ)।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਆਈਟਮ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਬਿਲਡਿੰਗ ਦੇ ਸਮੁੱਚੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਿਰਮਾਣ ਵਿੱਚ ਯੋਗਦਾਨ ਪਾਉਂਦੀ ਹੈ. ਇਹ ਕਈ ਤਕਨਾਲੋਜੀਆਂ ਵਿੱਚ ਕਿਉਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਇੱਕ ਵਿੱਚ ਨਹੀਂ, ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕ ਪਲੇਟਫਾਰਮ ਵਿੱਚ? ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਕਿਉਂਕਿ ਕੁਝ ਵਿਧੀਆਂ, ਸਾਡੀ ਰਾਏ ਵਿੱਚ, ਇੱਕ ਖਾਸ ਤੈਨਾਤੀ ਵਿਕਲਪ ਲਈ ਸੋਧਣ ਲਈ ਕਾਫ਼ੀ ਉਚਿਤ ਹਨ। ਪਰ ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਇੱਕ ਮੁਸ਼ਕਲ ਸਵਾਲ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਲਗਾਤਾਰ ਇੱਕ ਵਿਕਲਪ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ - ਮਲਟੀਟੇਨੈਂਸੀ ਦੇ ਇਸ ਜਾਂ ਉਸ ਪਹਿਲੂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਕਿਸ ਪੱਧਰ 'ਤੇ ਬਿਹਤਰ ਹੈ।

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਤੰਤਰ ਦਾ ਬੁਨਿਆਦੀ ਹਿੱਸਾ. ਖੈਰ, ਉਦਾਹਰਨ ਲਈ, ਅਸਲ ਡੇਟਾ ਵਿਭਾਜਨ. ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਲੋਕ ਆਮ ਤੌਰ 'ਤੇ ਮਲਟੀਟੇਨੈਂਸੀ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ। ਪਰ ਅੰਤ ਵਿੱਚ, ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਨੇ ਪਲੇਟਫਾਰਮ ਦੇ ਮਕੈਨਿਜ਼ਮ ਦੇ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਹਿੱਸੇ ਦੁਆਰਾ "ਯਾਤਰਾ" ਕੀਤੀ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੁਧਾਰ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਮੁੜ ਵਿਚਾਰ ਕਰਨਾ।

ਪਲੇਟਫਾਰਮ ਪੱਧਰ 'ਤੇ, ਅਸੀਂ ਬਿਲਕੁਲ ਬੁਨਿਆਦੀ ਵਿਧੀਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। ਉਹ ਤੁਹਾਨੂੰ ਇੱਕ ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ। ਪਰ ਅਜਿਹੇ ਮਾਡਲ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ "ਜੀਵਨ ਅਤੇ ਕੰਮ" ਕਰਨ ਲਈ, ਤੁਹਾਡੇ ਕੋਲ ਉਹਨਾਂ ਦੀਆਂ "ਜੀਵਨ ਗਤੀਵਿਧੀਆਂ" ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਸਿਸਟਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। 1c Fresh ਤਕਨਾਲੋਜੀਆਂ ਅਤੇ BSP ਪੱਧਰ 'ਤੇ ਇੱਕ ਏਕੀਕ੍ਰਿਤ ਵਪਾਰਕ ਤਰਕ ਪਰਤ ਇਸਦੇ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ। ਜਿਵੇਂ ਕਿ ਇੱਕ ਅਪਾਰਟਮੈਂਟ ਬਿਲਡਿੰਗ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਨਿਵਾਸੀਆਂ ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੀ ਹਰ ਚੀਜ਼ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਉਸੇ ਤਰ੍ਹਾਂ 1cFresh ਟੈਕਨਾਲੋਜੀ ਇੱਕ ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਵਿੱਚ ਚੱਲ ਰਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੀ ਹਰ ਚੀਜ਼ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਕਿ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ (ਬਿਨਾਂ ਮਹੱਤਵਪੂਰਨ ਸੋਧਾਂ ਦੇ) ਨਾਲ ਇੰਟਰੈਕਟ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਅਨੁਸਾਰੀ "ਕਨੈਕਟਰ" ਉਹਨਾਂ ਵਿੱਚ BSP ਸਬ-ਸਿਸਟਮ ਦੇ ਰੂਪ ਵਿੱਚ ਰੱਖੇ ਗਏ ਹਨ।

ਪਲੇਟਫਾਰਮ ਮਕੈਨਿਜ਼ਮ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਧਿਆਨ ਦੇਣਾ ਆਸਾਨ ਹੈ ਕਿ ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਅਨੁਭਵ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਅਤੇ ਕਲਾਉਡ ਵਰਤੋਂ ਕੇਸ “1C:Enterprise” ਨੂੰ ਵਿਕਸਿਤ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਇਸ ਢਾਂਚੇ ਵਿੱਚ ਸ਼ਾਮਲ ਵਿਧੀਆਂ ਦੀ ਰਚਨਾ ਦਾ ਵਿਸਤਾਰ ਕਰ ਰਹੇ ਹਾਂ। ਆਓ ਇੱਕ ਉਦਾਹਰਣ ਦੇਈਏ। ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ ਸੇਵਾ ਭਾਗੀਦਾਰਾਂ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ ਮਹੱਤਵਪੂਰਨ ਰੂਪ ਵਿੱਚ ਬਦਲਦੀਆਂ ਹਨ। ਓਪਰੇਟਿੰਗ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਲੋਕਾਂ ਦੀ ਭੂਮਿਕਾ (ਜ਼ਿੰਮੇਵਾਰੀ ਦਾ ਪੱਧਰ) ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਵਧਦੀ ਹੈ। ਉਹਨਾਂ ਲਈ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਕੰਟਰੋਲ ਟੂਲ ਹੋਣਾ ਜ਼ਰੂਰੀ ਹੋ ਗਿਆ। ਕਿਉਂਕਿ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ (ਨਿਵਾਸੀ) ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਪ੍ਰਦਾਤਾ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਨ ਜਿਸ ਨਾਲ ਉਹ ਕੰਮ ਕਰਦੇ ਹਨ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਲਾਗੂ ਕੀਤਾ ਸੁਰੱਖਿਆ ਪ੍ਰੋਫਾਈਲ ਵਿਧੀ. ਇਹ ਵਿਧੀ ਪ੍ਰਦਾਤਾ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਦੀ ਸੁਤੰਤਰਤਾ ਨੂੰ ਸੁਰੱਖਿਆ ਦੇ ਲੋੜੀਂਦੇ ਪੱਧਰ ਤੱਕ ਸੀਮਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ - ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਇੱਕ ਖਾਸ ਸੈਂਡਬੌਕਸ ਦੇ ਅੰਦਰ ਹਰੇਕ ਕਿਰਾਏਦਾਰ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਵਾਈ ਨੂੰ ਅਲੱਗ ਕਰਨ ਲਈ।

ਮਲਟੀਟੇਨੈਂਸੀ ਮੋਡ (ਜੋ 1cFresh ਅਤੇ BSP ਤਕਨਾਲੋਜੀਆਂ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ) ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਆਰਕੀਟੈਕਚਰ ਕੋਈ ਘੱਟ ਦਿਲਚਸਪ ਨਹੀਂ ਹੈ। ਇੱਥੇ, ਪਰੰਪਰਾਗਤ ਤੈਨਾਤੀ ਮਾਡਲ ਦੇ ਮੁਕਾਬਲੇ, ਪ੍ਰਬੰਧਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਆਟੋਮੇਸ਼ਨ ਲਈ ਲੋੜਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਹੋਇਆ ਹੈ। ਅਜਿਹੀਆਂ ਦਰਜਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ: ਨਵੇਂ ਡਾਟਾ ਖੇਤਰ (“ਅਪਾਰਟਮੈਂਟ”) ਬਣਾਉਣਾ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ, ਰੈਗੂਲੇਟਰੀ ਜਾਣਕਾਰੀ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ, ਬੈਕਅੱਪ ਆਦਿ। ਅਤੇ ਬੇਸ਼ਕ, ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਉਪਲਬਧਤਾ ਦੇ ਪੱਧਰ ਲਈ ਲੋੜਾਂ ਵਧ ਰਹੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਕੰਟਰੋਲ ਸਿਸਟਮ ਕੰਪੋਨੈਂਟਸ ਵਿਚਕਾਰ ਭਰੋਸੇਯੋਗ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਅਸੀਂ ਗਾਰੰਟੀਸ਼ੁਦਾ ਡਿਲੀਵਰੀ ਦੇ ਨਾਲ ਅਸਿੰਕ੍ਰੋਨਸ ਕਾਲ ਸਿਸਟਮ ਤਕਨਾਲੋਜੀ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ।

ਇੱਕ ਬਹੁਤ ਹੀ ਸੂਖਮ ਬਿੰਦੂ ਡੇਟਾ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਮਾਜਿਕ ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਹੈ। ਇਹ ਸਧਾਰਨ ਲੱਗਦਾ ਹੈ (ਜੇ ਇਹ ਕਿਸੇ ਨੂੰ ਲੱਗਦਾ ਹੈ) ਸਿਰਫ ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ. ਸਭ ਤੋਂ ਵੱਡੀ ਚੁਣੌਤੀ ਡੇਟਾ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਕੇਂਦਰੀਕਰਨ ਅਤੇ ਵਿਕੇਂਦਰੀਕਰਨ ਵਿਚਕਾਰ ਸੰਤੁਲਨ ਹੈ। ਇੱਕ ਪਾਸੇ, ਕੇਂਦਰੀਕਰਨ ਤੁਹਾਨੂੰ ਲਾਗਤਾਂ ਨੂੰ ਘਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ (ਡਿਸਕ ਸਪੇਸ, ਪ੍ਰੋਸੈਸਰ ਸਰੋਤ, ਪ੍ਰਬੰਧਕ ਦੇ ਯਤਨ...)। ਦੂਜੇ ਪਾਸੇ, ਇਹ "ਕਿਰਾਏਦਾਰਾਂ" ਦੀ ਆਜ਼ਾਦੀ ਨੂੰ ਸੀਮਤ ਕਰਦਾ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੇ "ਦੁਭਾਗੀਕਰਨ" ਦੇ ਪਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਜਦੋਂ ਡਿਵੈਲਪਰ ਨੂੰ ਸੌੜੇ ਅਰਥਾਂ ਵਿੱਚ (ਇੱਕ "ਅਪਾਰਟਮੈਂਟ" ਦੀ ਸੇਵਾ ਕਰਨਾ) ਅਤੇ ਵਿਆਪਕ ਅਰਥਾਂ ਵਿੱਚ (ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਾਰੇ "ਕਿਰਾਏਦਾਰਾਂ" ਦੀ ਸੇਵਾ ਕਰਨਾ) ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਬਾਰੇ ਇੱਕੋ ਸਮੇਂ ਸੋਚਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। .

ਅਜਿਹੀ "ਦੁਬਿਧਾ" ਦੀ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ, ਕੋਈ ਰੈਗੂਲੇਟਰੀ ਅਤੇ ਹਵਾਲਾ ਜਾਣਕਾਰੀ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਘਰ ਦੇ ਸਾਰੇ "ਕਿਰਾਏਦਾਰਾਂ" ਲਈ ਇਸਨੂੰ ਆਮ ਬਣਾਉਣ ਲਈ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਪਰਤਾਵਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਇੱਕ ਕਾਪੀ ਵਿੱਚ ਸਟੋਰ ਕਰਨ ਅਤੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਸਾਰਿਆਂ ਲਈ ਅਪਡੇਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਪਰ ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕੁਝ ਨਿਵਾਸੀਆਂ ਨੂੰ ਖਾਸ ਤਬਦੀਲੀਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਜੀਬ ਤੌਰ 'ਤੇ, ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਵਾਪਰਦਾ ਹੈ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਰੈਗੂਲੇਟਰਾਂ (ਸਰਕਾਰੀ ਸੰਸਥਾਵਾਂ) ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਜਾਣਕਾਰੀ ਲਈ ਵੀ। ਇਹ ਇੱਕ ਮੁਸ਼ਕਲ ਸਵਾਲ ਬਣ ਜਾਂਦਾ ਹੈ: ਸਮਾਜੀਕਰਨ ਕਰਨਾ ਜਾਂ ਨਹੀਂ? ਇਹ ਬੇਸ਼ੱਕ, ਹਰ ਕਿਸੇ ਲਈ ਜਾਣਕਾਰੀ ਨੂੰ ਆਮ ਅਤੇ ਉਹਨਾਂ ਲਈ ਨਿੱਜੀ ਬਣਾਉਣ ਲਈ ਲੁਭਾਉਣ ਵਾਲਾ ਹੈ ਜੋ ਇਸਨੂੰ ਚਾਹੁੰਦੇ ਹਨ। ਅਤੇ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਬਹੁਤ ਮੁਸ਼ਕਲ ਲਾਗੂ ਕਰਨ ਵੱਲ ਖੜਦਾ ਹੈ. ਪਰ ਅਸੀਂ ਇਸ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਾਂ ...

ਇਕ ਹੋਰ ਉਦਾਹਰਨ ਨਿਯਮਤ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਡਿਜ਼ਾਈਨ ਹੈ (ਇੱਕ ਅਨੁਸੂਚੀ 'ਤੇ ਚਲਾਇਆ ਗਿਆ, ਨਿਯੰਤਰਣ ਪ੍ਰਣਾਲੀ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ, ਆਦਿ)। ਇੱਕ ਪਾਸੇ, ਉਹਨਾਂ ਨੂੰ ਹਰੇਕ ਡੇਟਾ ਖੇਤਰ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਇਹ ਆਸਾਨ ਅਤੇ ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੈ। ਪਰ, ਦੂਜੇ ਪਾਸੇ, ਅਜਿਹੀ ਵਧੀਆ ਗ੍ਰੈਨਿਊਲਿਟੀ ਸਿਸਟਮ ਉੱਤੇ ਇੱਕ ਵੱਡਾ ਬੋਝ ਬਣਾਉਂਦੀ ਹੈ। ਲੋਡ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਸਮਾਜਿਕ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਪਰ ਉਹਨਾਂ ਨੂੰ ਵਧੇਰੇ ਧਿਆਨ ਨਾਲ ਅਧਿਐਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਬੇਸ਼ੱਕ, ਇਹ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਉਠਾਉਂਦਾ ਹੈ. ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਮਲਟੀਟੇਨੈਂਸੀ ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਨ? ਉਨ੍ਹਾਂ ਨੂੰ ਇਸ ਲਈ ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ? ਬੇਸ਼ੱਕ, ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਤਕਨਾਲੋਜੀ ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਮੁੱਦਿਆਂ ਦਾ ਬੋਝ ਸਪਲਾਈ ਕੀਤੀ ਤਕਨਾਲੋਜੀ ਦੇ ਮੋਢਿਆਂ 'ਤੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਡਿੱਗਦਾ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰ ਸਿਰਫ ਵਪਾਰਕ ਤਰਕ ਦੇ ਕੰਮਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚਦਾ ਹੈ। ਪਰ ਜਿਵੇਂ ਕਿ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਆਰਕੀਟੈਕਚਰਲ ਮੁੱਦਿਆਂ ਦੇ ਨਾਲ, ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਮਲਟੀਟੇਨੈਂਸੀ ਮਾਡਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਦੀ ਕੁਝ ਸਮਝ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਵੇਲੇ ਕੁਝ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਕਿਉਂ? ਕਿਉਂਕਿ ਅਜਿਹੇ ਨੁਕਤੇ ਹਨ ਜੋ ਡੇਟਾ ਦੇ ਅਰਥ ਵਿਗਿਆਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ ਤਕਨਾਲੋਜੀ ਆਪਣੇ ਆਪ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰ ਸਕਦੀ। ਉਦਾਹਰਨ ਲਈ, ਸੂਚਨਾ ਸਮਾਜੀਕਰਨ ਦੀਆਂ ਸੀਮਾਵਾਂ ਦੀ ਉਹੀ ਪਰਿਭਾਸ਼ਾ। ਪਰ ਅਸੀਂ ਇਨ੍ਹਾਂ ਮੁਸ਼ਕਲਾਂ ਨੂੰ ਛੋਟਾ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਅਜਿਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ।

1C:Enterprise ਵਿੱਚ ਮਲਟੀਟੇਨੈਂਸੀ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਇੱਕ ਹਾਈਬ੍ਰਿਡ ਮਾਡਲ ਬਣਾ ਰਹੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਮਲਟੀਟੇਨੈਂਸੀ ਮੋਡ ਅਤੇ ਆਮ ਮੋਡ ਦੋਵਾਂ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦੀ ਹੈ। ਇਹ ਬਹੁਤ ਔਖਾ ਕੰਮ ਹੈ ਅਤੇ ਇੱਕ ਵੱਖਰੀ ਚਰਚਾ ਦਾ ਵਿਸ਼ਾ ਹੈ।

ਸਰੋਤ: www.habr.com